When importing a GEDCOM, Family Historian takes the individual's name and puts it in the NAME tag. This applies even if the GIVN and SURN tags are in the file. When it does that it still leaves those two tags in the file. If at a later time there is a change of name, FH changes the NAME tag but not the other two. If that GEDCOM is then used as an input to another programme which uses the GIVN and SURN tags, incorrect information is imported. This issue probably arises for GEDCOM merges as well although I haven't had experience in that area.
I think Historian should either : (a) delete the SURN and GIVN tags when importing (my preference) or (b) if a change of name occurs, all three tags should be adjusted.
To me this problem is in the nature of a bug as it can create a database with incorrect information in it. Consequently I haven't put it in the Wish List request forum.
It's easy enough to remove them once you have imported, by creating a query which shows the two fields, and then select and delete them by pressing the delete button.
Jane (admin)
"Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad."
Yes you can if you know you have the problem but my point is that this conflict shouldn't arise and I think should be fixed by Calico Pie. Aside from anything else, many people wouldn't even be aware that the problem existed. I've now found this situation in three separate people's GEDCOMs and each of them had no idea what was causing it; they all were family history researchers not computer buffs. They just knew that the wrong information was turning up in the other programme. All three were using Family Historian at my recommendation and were not impressed by the situation.
I am going to move this to the wish list, as it will need to go to Calico, as the user group can't change the code and it will get missed in this forum.
Jane (admin)
"Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad."
The NPFX, GIVN, NICK, SPFX, SURN, and NSFX tags are provided optionally for systems that cannot operate effectively with less structured information. For current future compatibility, all systems must construct their names based on the <NAME_PERSONAL> structure. Those using the optional name pieces should assume that few systems will process them, and most will not provide the name pieces.
This suggests that there is no expectation that a compliant system should maintain optional tags for name pieces, e.g. GIVN and SURN. By the way the <NAME_PERSONAL> structure is what we are used to in FH, e.g.
code:
1 NAME Anthony Edward /Munro/
Note also that in this case, according to the standard, any entry for GIVN would have to be as follows, with a comma separating the two given names:
code:
1 NAME Anthony Edward /Munro/ 2 GIVN Anthony, Edward
This web site was made with WebAPP v0.9.9.3.3, a web portal system written in Perl
All trademarks and copyrights on this page are owned by their
respective owners. Comments are owned by the Poster.
Marble theme based on "Crash" theme by my2cents
Author:
Logged
Problem with use of NAME tag
