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.
http://www.fhug.org.uk/wishlist/wldispl ... lwlref=484
ID:5293
* Problem with use of NAME tag
- Jane
- Site Admin
- Posts: 8442
- Joined: 01 Nov 2002 15:00
- Family Historian: V7
- Location: Somerset, England
- Contact:
Problem with use of NAME tag
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
My Family History : My Photography "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad."
My Family History : My Photography "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad."
- jeemo
- Famous
- Posts: 129
- Joined: 04 Jun 2004 07:52
- Family Historian: V5
- Location: Central Coast, NSW, Australia
- Contact:
Problem with use of NAME tag
Jane
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.
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.
- Jane
- Site Admin
- Posts: 8442
- Joined: 01 Nov 2002 15:00
- Family Historian: V7
- Location: Somerset, England
- Contact:
Problem with use of NAME tag
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
My Family History : My Photography "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad."
My Family History : My Photography "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad."
Problem with use of NAME tag
Now on the wishlist.
This looks like something that will be pointed at when GEDCOM compliance is mentioned.
This looks like something that will be pointed at when GEDCOM compliance is mentioned.
- PeterR
- Megastar
- Posts: 1129
- Joined: 10 Jul 2006 16:55
- Family Historian: V7
- Location: Northumberland, UK
Problem with use of NAME tag
The GEDCOM 5.5 standard contains: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:
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 structure is what we are used to in FH, e.g.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 structure. Those using the optional name pieces should assume that few systems will process them, and most will not provide the name pieces.
Code: Select all
1 NAME Anthony Edward /Munro/Code: Select all
1 NAME Anthony Edward /Munro/
2 GIVN Anthony, EdwardPeter Richmond (researching Richmond, Bulman, Martin, Driscoll, Baxter, Hall, Dales, Tyrer)