Family Historian User Group

When you open the compare/merge files function FH first asks if you wish to validate the files. When the files have at some point previously been validated in FH, I always answer no to this. However, yesterday I found that the result of a merge of two validated files, did not validate and caused FH to lock up.

After the merge I did many hours work on the file and the lock up did not appear until the point I tried to click the button opposite the spouse name in the individual properties dialog in order to make the spouse the subject of the dialog. FH just hung and I had to 'end a non-responsive programme'. Fortunately I lost no edits because I was set to frequent automatic save.

After repeating the operations and getting the same result I tried validating the gedcom and to my surprise it reported an invalid gedcom. I allowed automatic correction with the folowing report:

Family Historian Validation Report - Thursday 23 Sep 2004
======================================

Individual Record Id=4705 (Daniel WILSON): Duplicate link to Family Record Id=1756 (...of Daniel WILSON and Ann WILSON).  Duplicate link has been removed.
Family Record Id=1756 (...of Daniel WILSON and Ann WILSON): Person listed as family member more than once.  Duplicate's Record Id=4705 (Daniel WILSON).  Duplicate family membership has been removed.
Family Record Id=1756 (...of Daniel WILSON and Ann WILSON): Individual listed as child has no link back to this family as a child.  Individual Id=4705 (Daniel WILSON).  Child field has been removed.

I should explain that individual 4705 (Daniel Wilson) is a son of the family 1756 (Daniel Wilson and Ann Wilson)

After this automatic correction the file seems fine with all relationships still present.


I think the reason for this occurence may have been that I incorrectly marked up the merge. If so, it is NOT an FH 'bug'. However, I thought I might ask the question, could or should FH protect the user from his errors and warn about a merge that will generate an invalid file from valid files? Obviously, now that I have encountered this problem, I can remember to a validate immediately after the merge to pick up problems, however with FH one can not then go back to the marked up merge and change it since there is no way of saving a marked up merge/compare.

I should add my merge yesterday took about 12 hours to mark up. I did not want to have to redo it.

ID:537

I think the recommended action is to always validate, but you are correct in the fact it should not happen.

With such a complex merge, I suspect it will be difficult or perhaps impossible to reproduce the error for Calico to fix.

Michael

thank you very much for your detailed and helpful description of what happened.  I should say at once that even if you made mistakes, Family Historian should never have generated an invalid file whatever you did, so it does sound as though there is a bug there.

Can you describe in more detail exactly what you think you did that may have caused the problem?  The information you have already provided will be helpful in tracking it down, but at some point, we really need to be able to reproduce the error ourselves.  So if you have any thoughts about how we might be able to do that, I'd much appreciate it if you could either post them here, or email them to me directly at simonorde@family-historian.co.uk.

Thanks

When the problem occured and I restarted FH, I saved a copy of the offending gedcom with a new name. I then fixed the problem by validating this file and later saved the fixed file back ontop of the original, so yunfortunately I think I have ended up with two copies of the corrected file!

I will try and write up more detailed report and email it, but unfortunately I have been doing so much over the last two days my memory of it is not what it might be.

Simon

I have now had a good look at the two input files which I tried to merge last night, which produced another occurence of the bug I reported yesterday.

I saved both files immediately before starting the merge.

Both files validate OK.

The marking up the merge took many hours. I was fairly thorough in checking the matched and unmatched records. I did a great deal of discarding of unwanted fields, and quite a large amount of matching of unmatched records.

There were at least two families which I could not match. As far as I remember this was because there was an additional (not quite identical) family record in the  master file, which appeared to match in the spouse names, but not in all other details. My memory was that the duplicate was in the master file panel. I just made the most approriate family match with the family in the merging file panel and left the other family in the master file panel unmatched.

After the merge, both these families report duplicate links on validation and hang when trying to navigate as before - These symptoms seem to be the identical to those I reported on the message board in my original report.

This morning I have done another file merge/compare on the two input files from last night. Amazingly both the families are matched with a 100 score. There are no duplicates to be found in the merge/compare display. I have also checked the parents for both families and these are well matched with no duplicates.

My tentative conclusion is that a long period of editing in the file compare/merge panel view has wrongly generated some duplicate families.

I hope this is of some help in suggesting the possible location of the problem. As far as being able to reproduce it at will, I am less optimistic. But when I next do a merge I will be very alert to the appearance of duplicate families.

Of course if there was the capability  to print a snapshot  of the merge/compare panel, or even to save a snapshot in some uncompleted form which could be later be resumed, it might be easier to capture the problem when it next occurs. the other great advantage, about which we coreesponded on the board in that I could send researchers a comparison report in order to direct further research.

Jane has already put this snapshot capability on the wish list, so I apologise for plugging this again, but it would be a great feature - and would make my work in dealing with all the Wilson researchers whose files I have been merging much easier. At the moment I make lists of major problems and dont have enough patience to document the minor discrepancies which I find in their gedcoms.

I can send you the two input files and the invalid post merge file if you want to play with them, but I hope my description will help. If I am right about it being a bug, then it should not be file dependant, but be due to some sequence in the marking up of merge/ compare process.

I have posted this on the message board to alert others to look out for the problem.

Michael

I've been communicating with Michael directly since this problem arose, so this posting is really for everyone else's benefit.

It turns out that there is indeed a bug in Merge/Compare which can in exceptional circumstances cause an invalid file to be generated.  This bug will be fixed in the next release of FH.  Meanwhile: you can still use Merge/Compare.  But you are recommended (a) to always take backups first and (b) to always run File > Validate afterwards, just to make sure that all is well (and to fix any problems found if it isn't).