Saturday, May 30, 2015

Another FTM Issue - Unattached Family Records in My Tree

As I reported here and here I am separating my Family Tree into multiple branches. I have discovered that there are thousands of unattached family records in each of my new branch files.

Reviewing my original Family Tree I also found over a hundred similar unattached family records in it.

I discovered this by reviewing the GEDCOM created by FTM when I export some or all of a tree. These unattached records have no HUSB or WIFE records associated with them and float around the database. For example:

0 @F408@ FAM
2 DATE 12 DEC 1700
2 PLAC Suffield, Hartford County, Connecticut


I just discovered unattached family records with nothing but the level 0 GEDCOM record. Here is a section of the GEDCOM. These are also NOT removed by compacting.

0 @F18656@ FAM
2 DATE 27 FEB 1707/08
2 PLAC Newton, Middlesex, Massachusetts, USA
0 @F18659@ FAM
0 @F18660@ FAM
0 @F18662@ FAM
2 DATE 26 NOV 1919
2 PLAC Proctor, St Louis, Minnesota, USA
0 @F18667@ FAM
0 @F18670@ FAM
0 @F18671@ FAM                            
Updated 6/3/2015

Because they are not attached to an individual, I can find no way to manually delete them from the database from inside FTM.

I have tried several tricks to fix this but to no avail. Compacting the file does not fix the problem. Nor does the export of the Tree to a different FTM file rather than directly to a GEDCOM file.  Years ago there was a workaround for repairing a tree, But this no long works.

At this point in my project, I  think my only choices are; live with the problem, edit the GEDCOM file and manually delete each GEDCOM entry, or I could write a program to do those deletions.

Those two latter options would require a load of new databases with the corrected GEDCOM and a manual reload all of the associated media. None of this is to my liking. I hope that this post will result in someone offering a much better solution.

How is this caused? In my case and in this recent project I often used several of the reports that allow selection and deletion of groups of individuals. I suspect that one or all of these deletions are done without regard to the family and/or marriage records of those individuals. If this is true it demonstrates some very lax testing on their part. This seems to be a continuing theme.

I cannot explain the presence of the unattached records in my original file. This file has been in effect for nearly 15 years and has undergone various updates as I have implemented new releases. It could stem from data entry errors I have made in entering new information, deleting miss-entered individuals, or as the result of merging GEDCOM files, with these errors in them, into my tree. But they do exist and, in my mind, FTM should not allow them to exist.

But, perhaps I am wrong and FTM did intensive testing and discovered this and other errors and they made a conscious business decision to ignore the issues.

Is this specific issue a major problem? Not really. The tree will still be processed, reports and charts will not be affected. However, processing time will be longer as a result and, more importantly, the errors will be perpetuated as we generate GEDCOM.

What this issue does demonstrate, once again, is the lack of attention to detail that we repeated see in the product. This software is not free and many of us repeatedly purchase upgrades in the hopes that the new release will be an improvement over previous releases.

I continue to be disappointed and frustrated.  


  1. This is a strange bug indeed and should definitely be reported to the developer. You should also volunteer to be a beta tester for the next version, assuming you want to continue using FTM. I was a beta tester for the latest Mac version, and I can tell you that we reported many bugs that were fixed before the final version was released. It's very difficult to test every aspect of a program. For example, I tested the GEDCOM export function, but I did not see this problem, nor would I have known to even look for it.

    You say you tried "the export of the Tree to a different FTM file," but did you try exporting the tree from the Extended Family Chart ( This is supposed to get rid of orphaned/corrupted records and files. The article is for the Mac version, but the steps should be similar for Windows.

  2. I did not. However, since I have very many interconnected families in the source database I suspect I would still have the issue I am dealing with trying to separate the data into branches today. It is my fault for overloading FTM with more data than it can handle. I hope this serves as a caution for others.

    I would appreciate if someone would point me to a review that discusses volume testing of the top genealogy software.

    The issue discussed in this post is specific to FTM and how poorly it manages the data in the database and the lack of tools for users to manage that data. That is the point I wanted to emphasize.

    I firmly believe that we all are testers of the software we use. The providers of our software, especially the ones we pay for, have an opportunity if they choose, to receive feedback via our forums, emails, and blogs. FTM, in my opinion, chooses to ignore that feedback.

  3. After posting the above comment, I found this page about stress testing.
    Thanks Tamura