* Ancestry Sync plugin question

[Coolgarra]

I am using Ancestry Synchronization plugin V2.3 & FH 7.0.22.

I have had to merge 2 files, and now find that, for a few hundred individuals, there are 2 UIDs.

When I look in RootsMagic I cannot find any evidence of these, and am wondering if there is going to be an issue or not when I run the Ancestry Sync plugin?

Chris

[Mark1834]

RM requires a single UniqueID for all individuals, but never displays it in the normal user interface, so it cannot be inspected without using more specialist software.

The plugin manages this by only exporting the first value in the GEDCOM file, and ignores additional FH values when comparing records, so it shouldn’t be a problem.

GEDCOM 7 supports multiple values of the UniqueID, but if you want to delete the additional values you can create a custom query listing %INDI._UID[2]% data references and deleting them.

[Coolgarra]

Thanks Mark. I think I'll be making a backup prior to doing anything.

I have made a query to see the double-ups, but I'm wondering whether it would be UID1 or UID2 that matches up with the individual in RootsMagic. I wouldn't want to delete the wrong one. I guess I should have mentioned that I have previously done an export to RM and synced to Ancestry and this will be a subsequent update.

Chris

[jelv]

You cant see the UID in RootsMagic unless you use something like https://sqlitebrowser.org/ to look inside the RM database.

You can't see it via the Ancestry website, but if you export the tree from Ancestry as a GEDCOM you can see them in there.

[Coolgarra]

Thanks John - I'll give it a go. I was wondering about the SQLITE tool.

Chris

[Mark1834]

There are potential consequences here that have not arisen before. When CP added support for UniqueID in FH7.0.8, they adopted the GEDCOM 7 definition whereby it can have any number of values, including none.

In RM, it’s the database primary key for individuals, so must be present and be unique within that database.

As a result, FH allows the UniqueID to be changed, but RM does not. If %INDI._UID[1]% is changed, RM will regard it as a different individual when importing. Subsequent comparisons will highlight the “old” version as requiring manual deletion, and Ancestry hint continuity will be broken as it’s now a different person in RM/Ancestry.

It’s probably fixable with a plugin modification, but it will need a bit of experimenting to confirm exactly how RM responds to attempted changes in UniqueID.

[Coolgarra]

Thanks Mark!

Yes, I foolishly didn't think about the consequences of merging 2 files, which meant people might end up with 2 UIDs, BEFORE I did it! (Although, I do have a backup of the 'before' state).

Luckily, this particular Family Historian database is reasonably small, so it's a lesson learnt that will be 'reasonably' easy to sort out.

[Mark1834]

Out of interest, I have been experimenting to see exactly how changes to UniqueID are handled in RootsMagic.

UniqueID is a required field for new individuals in RM. It is created automatically for any new individual added from the normal user interface (UI), or added if missing to individuals imported via GEDCOM.

There is no way to view or change the UniqueID from the normal UI. However, the program does not object if it is changed (or even deleted altogether) by specialist database tools, including via this FH plugin. All internal links are via the PersonID field, equivalent to the FH Record ID, so once created the UniqueID is just another property field.

In principle, that means that the plugin could manipulate both FH and RM UniqueID values. However, I don't want to do that, as UniqueID is designed to be immutable. Once created, it should never be changed.

I have therefore limited plugin changes to simply warning the user if any of the FH Individuals have multiple UniqueID values associated with them, and added a warming against merging records to the help file. There were also a couple of other potential issues raised in recent threads, but not pursued by the original poster as they did not recur. Even if the user makes a mistake, the plugin should not crash, so I have also added a couple of changes to make it more robust to potential causes, and to fix the known issue with unnamed individuals, which FH supports, but RM does not.

The new version (2.3.1) can be downloaded here if anybody wants to try it out. I probably won't update the store for a while, as I want to use it myself for a period first.

[Coolgarra]

Thanks Mark. I have downloaded and am testing V 2.3.1
I can confirm that it lets me know if there is a duplicate UID (which occurred due to a merge).
I like the extra detail in the Research Note.
Chris