Friday, September 7, 2012

Task 3 - Upload GEDCOM File to Legacy Family Tree 7.5

In Problems in RM5, LFT7.5, FTM2012 and Ancestry Member Trees  (3 September 2012), I noted two problems when I went from my RootsMagic 5 file to a GEDCOM file to a Legacy Family Tree 7.5 file to a second GEDCOM file to a Family Tree Maker 2012 file to as new Ancestry Member Tree.  The two problems with the resulting tree were that:

*  Some of the "double dates" were wrong (one said "0001-20 March 1630" when it should have said "20 March 1630/1")

*  Some long Source Citation details (more than 255 characters) were truncated.

I showed in the referenced post that the GEDCOM created by RootsMagic 5 had correct double dates for Sarah Pray and a complete source citation detail for the 1920 U.S. census for Frank Walton Seaver.  

In the referenced post, I set out three tasks to investigate where these problems occurred.  The first task was to create a GEDCOM file from my RootsMagic 5 database and upload it to a new Ancestry Member Tree, which I did in Task 1 - Upload RootsMagic 5 GEDCOM file to Ancestry Member Tree.

The second task was to upload the same GEDCOM file to Family Tree Maker 2012, review the issues, and then upload the FTM2012 tree to a new Ancestry Member Tree using the TreeSync feature.  I split this effort into two posts - first Task 2a - Upload GEDCOM File to Family Tree Maker 2012 and Task 2B - 

The third task was to upload the GEDCOM file (created in RootsMagic 5) to a new Legacy Family Tree 7.5 database, and evaluate the problems found in the first referenced post.  The two problems seen were:

1)  Some of the "Double Date" entries were scrambled, in the form of "0001-20 March 1630" when it should have been "20 March 1630/31."  

Before I imported the GEDCOM file, I made sure that the box for using Double Dates in Legacy Family Tree was checked (Options menu > Customize > Dates tab, check "Use double dating" in "Double Date Cutoff section).

After the GEDCOM import, I navigated to Sarah Pray (1631-1677) and clicked on her to get the "Individual's Information" and saw:

On the screen above, the Birth Date Fact says "Before 0001-20 March 1630," and the Christening Date Fact says "0001-20 March 1630," when the dates should be 20 March 1630/31.

I edited the two Dates by typing "20 Mar 1631" and the dates changed to "20 March 1630/31."  Here is the screen before I clicked on "Save:"

After clicking "Save," the Family view screen for Sarah Pray looks like this:

I've looked through the Index for about 5% of my 41,000 persons in this database, and saw only four instances where something like this happened.  Three of them were in one Pray family, the one that included Sarah.  The vast majority of the Double Dates I saw in the Index were correct.

As far as I can tell, the Double Date feature works well in Legacy Family Tree 7.5, except for these isolated instances.  I've tested adding a date that should be a Double Date (e.g., 20 March 1631), and Legacy Family Tree translates that to 20 March 1630/1.  It always adds the earlier year  to create the Double Date.  

I have no idea how this happened... as I showed in my first post in the series, the GEDCOM lines for these dates look good to me.  

2)  The Truncated Source Citation Detail:  Using the same example as in previous posts, I looked at the 1920 United States Census for Frank Walton Seaver.  Here is Frank's "Individual's Information" screen:

The "Census" Fact for the 1920 Census shows the location, but indicates that there is no Source attached to that Fact.  This is the case for some of the "Census" Facts (1880, 1900, 1910, 1920) for this one person with those Facts (but they are attached for the 1860 and 1870 Census Facts).  Other persons have Census Facts with Sources indicated.  In the GEDCOM file, there were Sources for the "Census" Facts.

I have no idea why they do not display for the Census Facts for this person in Legacy Family Tree 7.5.  His wife has Sources attached to the Census Fact, as do his son and his parents.  Strange!

The "Occupation" Fact for the 1920 Census does have a Source Citation indicated, so I clicked on the "Sources" icon (the three books to the right of the surname) to see the Sources for Frank Walton Seaver, and clicked on the Occupation Fact for the 1920 Census:

In the screen above, you can see that there is no Source for the 1880, 1900, 1910 and 1920 Census Facts.  The Source Citation for the Occupation Fact (highlighted on the screen above) that the Footnote/Endnote Citation is:

1920 United States Federal Census, Population Schedule, Worcester County, Massachusetts, Leominster; Supervisor District 3, Enumeration District 102, Sheet 5B, dwelling #68, family #132, lines 7-10, Frank W. Seaver household;  online database, (; citing National Archives Mi. 

As you can see, the Citation Detail (after "Population Schedule") has been truncated after 255 characters.  The "Subsequent Citation" is also truncated.  

As I showed in the first post in this series, the GEDCOM file includes the complete Citation Detail (in the PAGE tag).  

So what I learned in this experiment was that exporting a GEDCOM file (created by RootsMagic 5) to a Legacy Family Tree 7.5 database resulted in:

*  The GEDCOM file upload for my 41,261 person tree with 30,000 source citations took about 5 minutes to upload to Legacy Family Tree 7.5.

*  Of the 515 Media links (to images in my computer files) that I had attached to my RootsMagic 5 tree, and which had links to the images in the GEDCOM file, I can't find a way to count them in Legacy Family Tree 7.5.   I do see a lot of them!

*  Legacy Family Tree 7.5 uploaded most of the "Double Dates" correctly (perhaps more than 95% of them), and displayed most of them correctly in the "Individual's Information" screen.  However, some were not displayed correctly, but could be edited to be correct.

*  Legacy Family Tree 7.5 did not find "Census" Fact information, or Source Citation information for some Census Facts, for at least one person for some unknown reason.

*  Legacy Family Tree 7.5 truncated long Source Citation Detail text to 255 characters in all instances.

I hope that the Legacy Family Tree developers will see this post and investigate the problems noted above.  I will be happy to provide a small GEDCOM file for the problems noted above.

The URL for this post is:

Copyright (c) 2012, Randall J. Seaver

1 comment:

Cousin Russ said...


Could this 255 or 256 truncation issue be a GEDCOM 5.5 or GEDCOM 5.5.1 limitation?

I went to the GEDCOM website

and found this:

A free form text block used to describe the source from which information was obtained. This text block is used by those systems which cannot use a pointer to a source record. It must contain a descriptive title, who created the work, where and when it was created, and where is source data stored. The developer should encourage users to use an appropriate style for forming this free form bibliographic reference. Developers are encouraged to support the SOURCE_RECORD method of reporting bibliographic reference descriptions.

At the top of that listing, talks about 248, but what does that mean. Earlier, on that website, that number would indicate the "minimum" field length.

Here is that quote:

The field sizes show the minimum recommended field length within a database that is constrained to fixed length fields. The field sizes are in addition to the GEDCOM level and tag overhead. GEDCOM lines are limited to 255 characters. However, the CONCatenation or CONTinuation tags can be used to expand a field beyond this limit. CONT line implies that a new line should appear to preserve formatting. CONC implies concatenation to the previous line without a new line. This is used so that a text note or description can be processed (word wrapped) in a text window without fixed carriage returns. The CONT and CONC tags are being used to extend specified textual values.

Please understand and am NOT a GEDCOM expert, but IF I have read this correctly, this truncation issue is in the implementation of the (very old) GEDCOM "standards".

Perhaps a GEDCOM expert or software developer can help clarify this for us.