Family Historian User Group

I've downloaded some GEDCOMs from FamilySearch (the old site). On importing them into Version 5 of Family Historian the parents are mis-imported! Instead of having a father and a mother for the child I have a mother and a sibling - both the same female individual. The father's name is discarded. I have inspected the GEDCOMs in notepad and they are good to go, both mother and father exist and are correctly formed.[cry]

ID:6203

If they were correctly formed I don't think they would be misimported as Family Historian uses GEDCOM as its method of recording data so effectively it isn't importing, it is just interpreting the GEDCOM directly.

If you paste the code into a reply to this forum thread then we should be able to see what is going wrong.

Cheers

Nick

In over 30 years of using GEDCOM data from the Family Search site I've not had one that is malformed, much less two. I wish I'd kept a copy of FH4 to compare against
I'll paste the GEDCOM into another reply after I've tested it against Roots Magic 5.

I've noticed those sorts of erros too. I'm fairly certain I was still using v4 at the time. For me it started when they introduced the new site.

The key is to open the Family Search gedcom first and make sure that's all correct before you start importing/merging into your project. I found that the downloaded gedcom somehow was wrong, even when I opened it in PAF.

Forgot to say, downloading the gedcom for an individaul is wrong, the family is not or vice versa, can't remember now. It does it only on 1 set of records. Look at the person in the other view and download that gedcom and it's fine.

Hi All
I've created a Roots Magic database with both offending files and they have both worked perfectly with no errors reported, one was imported into a database to see if there was a difference in the mechanism of import against creation (no reason to suspect there would be, but you never know). One of the offending files is pasted herein:

0 HEAD
1 SOUR IGI
2 VERS 5.0
2 NAME International Genealogical Index (R)
2 CORP The Church of Jesus Christ of Latter-day Saints
3 ADDR 50 East North Temple Street
4 CONT Salt Lake City, Utah 84150
2 DATA International Genealogical Index
3 DATE 1 May 2012
3 COPR Copyright (c) 1980, 2002
1 DEST PAF
1 DATE 1 May 2012
2 TIME 05:56:47
1 FILE BELL-1774
1 GEDC
2 VERS 5.5
2 FORM LINEAGE-LINKED
1 CHAR ANSEL
1 SUBM @SUB01@
1 SUBN @N01@
0 @SUB01@ SUBM
1 NAME Created by FamilySearch (TM) Internet Genealogy Service
1 ADDR 50 East North Temple Street
2 CONT Salt Lake City, Utah 84150
0 @N01@ SUBN
1 DESC 1
1 ORDI N
0 @I500169664416@ INDI
1 NAME SARAH
1 SEX F
1 FAMS @F162074699@
1 SOUR @S01@
0 @I500169664415@ INDI
1 NAME ROBERT /BELL/
1 SEX M
1 FAMS @F162074699@
1 SOUR @S01@
0 @I500169664414@ INDI
1 NAME ROBERT /BELL/
1 SEX M
1 CHR
2 DATE JUL 1774
2 PLAC Skelton By Guisborough, Yorkshire, England
1 FAMC @F162074699@
1 SOUR @S01@
2 PAGE Batch #: C109602, Sheet #: 00, Source Call #: 0919077, Printout Call #: 6911305, Dates: 1727 - 1813
0 @F162074699@ FAM
1 HUSB @I500169664415@
1 WIFE @I500169664416@
1 CHIL @I500169664414@
0 @S01@ SOUR
1 AUTH The Church of Jesus Christ of Latter-day Saints
1 TITL International Genealogical Index (R)
1 PUBL Copyright (c) 1980, 2002, data as of May 1, 2012
1 REPO @R01@
0 @R01@ REPO
1 NAME Family History Library
1 ADDR 35 N West Temple Street
2 CONT Salt Lake City, Utah 84150 USA
0 TRLR

As I said, I can see nothing wrong with it and neither can Roots Magic.

Hmmmmmmm......I created a test project using the GEDCOM as a basis and Family historian couldn't import the GEDCOM, generating an exception report. The error given was that all the record IDs were the same and the imported file showed that FH had assigned the same record ID to all of the records in the file - despite this clearly not being the case.[confused]
The one record ID generated by FH bears no resemblance to any of the record IDs in the riginal GEDCOM file.
Guess I'll be using Roots Magic 5 until this problem is resolved.

Here is FH 5s version of the GEDCOM:

0 HEAD
1 SOUR FAMILY_HISTORIAN
2 VERS 5.0
2 NAME Family Historian
2 CORP Calico Pie Limited
1 FILE I:DocumentsFamily Historian ProjectsBELL-1774BELL-1774.fh_dataBELL-1774.ged
1 GEDC
2 VERS 5.5
2 FORM LINEAGE-LINKED
1 CHAR ANSI
1 DEST PAF
1 SUBM @U1@
1 SUBN @B1@
1 _UID {10DB19DC-131A-44a4-8FA5-2739E3095489}
1 _LIST Key Individuals
1 _LIST Work in Progress
1 _LIST Bookmarks
1 _ROOT @I2147483647@
0 @I2147483647@ INDI
1 NAME SARAH //
1 SEX F
1 SOUR @S1@
1 CHAN
2 DATE 2 MAY 2012
3 TIME 11:29:57
0 @I2147483647@ INDI
1 NAME ROBERT /BELL/
1 SEX M
1 SOUR @S1@
1 CHAN
2 DATE 2 MAY 2012
3 TIME 11:29:57
0 @I2147483647@ INDI
1 NAME ROBERT /BELL/
1 SEX M
1 CHR
2 DATE JUL 1774
2 PLAC Skelton By Guisborough, Yorkshire, England
1 SOUR @S1@
2 PAGE Batch #: C109602, Sheet #: 00, Source Call #: 0919077, Printout Call #: 6911305, Dates: 1727 - 1813
1 CHAN
2 DATE 2 MAY 2012
3 TIME 11:29:57
0 @R1@ REPO
1 NAME Family History Library
1 ADDR 35 N West Temple Street
2 CONT Salt Lake City, Utah 84150 USA
0 @S1@ SOUR
1 AUTH The Church of Jesus Christ of Latter-day Saints
1 TITL International Genealogical Index (R)
1 PUBL Copyright (c) 1980, 2002, data as of May 1, 2012
1 REPO @R1@
0 @U1@ SUBM
1 NAME Created by FamilySearch (TM) Internet Genealogy Service
1 ADDR 50 East North Temple Street
2 CONT Salt Lake City, Utah 84150
0 @B1@ SUBN
1 DESC 1
0 TRLR

The problem is caused by the long INDIvidual Record Id.
If the I500 is replaced globally by I using a plain text editor, then the GEDCOM opens in FH OK.

I believe this is a fault in FH, because the GEDCOM Specification says the cross-reference ID has a maximum of 22 characters, including the enclosing ‘at’ signs (@).
FH appears to be supporting only 14 characters.

I'd go with that - although FH does say that the numeric portion of the Record ID is retained as the Record ID. In theory though each record ID should still be different - must be a parsing error that isn't being trapped.
It is also a new problem in FH 5 - FH 4 used to work fine.

This is certainly a bug in FH. Further to tatewise's observation, I noticed that the duplicate Individual IDs are I2147483647 and the numeric part is 2^31-1, which is often the largest possible number that can be represented using four bytes. FH tries to retain the IDs used in the imported file, but fails if this would involve numeric values greater than 2147483647.

The FH 3.0 Demo will also load that GEDCOM OK but does change the Individual record IDs.

Never thought of using the FH3 demo - dohhhh!
Looks like FH needs another number type as a container for Gedcom IDs.

It's more to do with 32 bit vs 64 bit, the ID's as produced by FamilySearch convert to numbers which are 64bit rather than 32bit, but saying that Simon has changed the way FH deals with this. Best shown using Binary

500169664414 - 111010001110100011011110110011110011110
    1953458078 -               1110100011011110110011110011110
    2147483647 -               1111111111111111111111111111111

First Line FamilySearch ID, 2nd Line ID as produced by FH v3 Demo, 3rd line produced by V5.

So looks like instead of chopping Bytes off the front is doing actual covert which will give the value as shown.

Regardless of whether it is 64-bit or 32-bit, or anything else, FH claims to be GEDCOM 5.5 compliant.

GEDCOM 5.5 says cross-reference ID have a maximum of 22 characters, including the enclosing ‘at’ signs (@).

FH does not support that number of characters, and so it is failing in its claim of being compliant.

I don't really care how FH or PC represent numbers. FH should be compliant. If that needs two 32-bit numbers, then so be it.

That is true - compliance is compliance. It shouldn't actually change any numbers unless asked by the user (ie to fit with another number scheme already in use)

Looking at

http://www.family-historian.co.uk/downl ... ee-upgrade


This is should be fixed in V5.0.1 please can you confirm it is still not working with the latest version.

FH V5.0.1 does cope with the large Record Id, but not as I had expected.
FH V5.0.1 appears to completely renumber all imported Records starting from 1, rather than retain the original Record Id.

Earlier FH versions did try and retain much of the original Record Id.

The strategies used by FH when importing from another program could be better described in the Help page 'Transferring Data into Family Historian'.
It could explain about renumbering Record Id, about checks for UDF, about the Reports that might be generated, and how to interpret them.

I think I am right in saying that some of the above applies even when opening a Project/GEDCOM from an earlier version of FH.
The Reports created in this latter case, regularly raise postings on FHUG Forums, asking what the Reports mean and why FH V4 did not create similar Reports.

It seems that the renumbering of IDs by FH v5.0.1 only occurs if an ID in the file being loaded is too long.  Using the earlier example GEDCOM, above, if the Individual IDs are shortened to I169664414, etc., then they and the original Family ID are loaded by FH unchanged.

Yes, any large Record XRef causes all Record Id to be renumbered from 1.

FH does have a challenge here when importing from other programs, because the GEDCOM 5.5 Specification does not require Record Xref to be numerical.
They can be any character string as long as each one is unique.
So I guess, if FH finds a numerical portion that is small enough in every Record XRef it uses that number.
Otherwise, it renumbers everything.

This is why some explanation in the Help would be helpful.

Interestingly mine says that V5.0.0 is the latest version when I ask it to check for updates.

You need to download 5.0.1 manually using the link, it's not on automatic release yet.