Reply

Basically the answer is that if the system says you need to renumber, then you need to renumber. Don’t try to second guess it.

When it refers to XREFs it is referring to ALL of these: INDI, FAM, NOTE, SOUR REPO and OBJE.

Using A vs I shouldn’t matter, as long as you have that set in your configuration for both trees. The renumbering should use that setting so don’t bother changing the letter anywhere. If it appears to cause a problem after following the exact FAQ instructions, send me both GEDCOM files so I can test and identify if the fault is the data or the code. (Incidentally A1234 is unique from I1234. They are not the same XREF)

I think the answers to your other questions lie in remembering what APPEND is. It really is exactly that – apart from ensuring all XREFs are unique it simply sticks the data from new file on the end of the old data for each record type. Absolutely no attempt at merging is done. So if each file has a reference to the same source, then the new larger file will have that source included twice. Same applies to all the XREF types. .

For the most part I’d say 90-95% of the records imported intact.

That means it failed. Anything less than 100% is a fail and should be re-run. The proper check is simply that the new record count for every record type should be exactly the sum of the two appended files. A “Statistics block” included on the Home page of each tree is a good tool to see these counts. If it keeps failing, send me both GEDCOM files so I can test and identify if the fault is the data or the code.

I also do recommend you follow the guidance about exporting copies of your data to fresh new GEDCOM files. It’s a good habit to get into, and avoids the risk that you have updated something on the database that isn’t in your other copy, but you forgot about it.

Nigel
My personal kiwitrees site is www.our-families.info