Jump to content


mleroux

Member Since 03 Jan 2016
Offline Last Active Sep 27 2016 12:01 PM
-----

Posts I've Made

In Topic: Count Trees Issue?

18 September 2016 - 08:09 AM

Depends on definitions, of course. To me if all branches are connected then it is one "tree". Count Trees is under tools, and I use it as such - identify people that have not yet been connected - so I can make the leap that these would be separate "trees"


In Topic: Automatic Sorting

19 August 2016 - 09:49 AM

I use, and very much appreciate, the script that Tom created, and I do so because I have cases where I want to do it in a batch format. As RM adds more import capabilities this may become even more important. If it is an option for the user to invoke on a manual basis - aka informed usage - then I (personally) don't really see this as a problem. From a product perspective I can see some of the challenges - there have to be additional reports, perhaps additional data fields to indicate which ones were automatically sorted, etc.. From my perspective it doesn't really affect me (I have Tom's solution) but I can see where it would be very useful for those that aren't comfortable a SQL manager.

 

In the back of my mind I have been thinking of a related tool that analyzes families and based on the data identifies "missing" people. For example if a family has children every 13 months and there is a 2 year gap there may have been a stillborn child, or perhaps a missing person or one of the undated births.


In Topic: Custom Report

19 August 2016 - 09:28 AM

The genealogical standard I use for estimating dates is: the man was 25, the women 21 when married, first child 1 year after marriage and each child 2 years following the other. I cite myself as the source and how the date was estimated.  For multiple marriage I will use bef and after dates to help control the order.

 

I had a very bad experience, inheriting a database that had a tremendous number of estimated dates. Coupled with a genealogy that has several commonly used names, often within the same family (child dies, next born has the same name) it led me to spending a tremendous amount of time cleaning up duplicate names because the estimated dates were often very different from actual dates. Granted, this is primarily with births, but once that is off, then marriage dates were also off - or just didn't make sense when I found a record.

Bottom line, I don't like estimated dates.

 

I also believed that there are other factors - gender (as Renee mentions), but also differentiating life expectancy (death - birth) and life span (death - birth excluding children that died), and also the time frame, possibly also the region. Scientists say that life span has basically not changed for 2000 years and is between 70 and 80 years old and the presumption is that they are much smarter than I am, but I haven't come across much that deals with the age people get married. I was working on something else, and it was a fairly easy extension, so I compiled a table from the data in RM for my database. I think I am correct that marriage age varies over time and the data supports life expectancy being fairly constant, although in my family, significantly less than the "standard" of 70-80 years

 

Every database will be different, of course, and all the caveats of accuracy of data apply, but hopefully this is of some use/interest to others:

2016-08-19_11-07-54.jpg

 

If some applies the discipline to estimating dates that Renee has with her documentation approach, and recognizes the challenges, then perhaps I'm starting to come around to the idea of estimating dates.


In Topic: Automatic Sorting

16 August 2016 - 01:33 PM

Go to Edit>Rearrange and select either Children or Spouses.

On the Family View you can also click on the double arrow icon next to the children to sort them. 

Note that these must be done on a family by family basis, whereas Tom's scripts will run on all families, so it depends what you are looking for.


In Topic: Reconciling Statistics Report

16 August 2016 - 01:25 PM

Agreed, it does make sense - once it's been explained.

 

I am off by a considerable amount if I run Tom's query (1205) and the report (1188) so there is something slightly off. Perhaps some of the conditional dates (after, before, about, between) are excluded. I get a closer number (1198) when I exclude these (changing the date check for birth/marriage to "like 'D.%'). There may be some of the approximate dates (date position 13) that are also excluded, but I can't seem to find a combination that gets me closer. There are a lot of possibilities and no guarantee that I'd be correct  even if I managed to get the numbers to match.