UniqueID in PersonTable
Have any of you done any research in how the UniqueID in PersonTable is used?
Under what conditions is it preserved or swapped?
etc.
Is it like a GUID in that parts of the ID are taken from a machine's ethernet MAC address etc?
The UniqueID is exported to GEDCOM in a custom tag and survives both the current drag'n'drop and the former based on GEDCOM export-import. It's key to collaboration with other RM databases whose trees overlap as it unambiguously identifies duplicate people who originated in the same database. I tried extending that through Ancestry and FTM2014 before the advent of TreeShare which superseded that effort. Ancestry.com Sync #ancestrycom#gedcom#ftm2014
Thanks for that.
I'm wondering about merging people with te same vs different UniqueID.
I'll look into it when I get some time.
Sort of amplifying on what Tom said:
It was introduced as a part of ShareMerge. The concept is that you could export some GEDCOM and send it to a colleague who also was running RM. The colleague would update the data and send it back to you. As Tom said, the UniqueID would survive the round trip. Then the theory was that you could simply do a ShareMerge which would be an automatic merge based on the UniqueID and you were done. It was supposed to be as simple as that. Except it wasn't.
I tried using the feature to share with myself. I export GEDCOM for a family I was working on, imported the GEDCOM into a new and otherwise empty RM database, updated the data, exported it back to the original database, and ran a ShareMerge.
All it did was to do a standard person by person merge of individuals with the same UniqueID. I still had to go through each merged person and cleanup any duplicate data - like if I had updated a Birth record for somebody while I was working in the little database, I would have two Birth facts for the individual after the ShareMerge to cleanup just as I would after any other merge where the birth data was different. And it was hard to find the people who needed the additional work.
It seemed to more than double my work, and I didn't play with the idea very long. What it amounted to was that I felt that I needed a Replace option rather than a Merge option, where the recently imported data for the person was a complete replacement rather than a merge.
As far as the algorithm for generating the UniqueID, all I remember is that it was supposed to be sort of random-ish and yet still guaranteed to be unique with respect to any other UniqueID values generated by RM anywhere or anytime in the world.
In summary, I think the only purpose of the UniqueID is to support ShareMerge.
You can merge people with different UniqueID's just fine. It happens all the time.
Only one of the UniqueID's survives. For manual merges, it's the one on the left of the Merge screen. I'm not sure what the algorithm for retaining UniqueID's is on automatic merges. And remember that ShareMerge is not the only automatic merge.
In addition to ShareMerge, Compare Files flags those having the same UID as definite duplicates. Beyond that, Jerry's point about a Replace as an alternative to what is essentially a Combine is applicable.
I am trying to create a new person record from a Python program. Is there a way to create a Unique ID from a script?
This query on CoPilot offers some ideas to explore. Whether they result in something that is compatible with RM's is up to you to find out!
https://copilot.microsoft.com/chats/thZVENFixwGaGRPb8NCsE
If that link doesn't work, the question I posed was "how to generate a universal unique id in SQLite". I was surprised at getting what seems a good quality answer.
Let us know how you get on!
I suspected and confirmed that there is a UUID extension for SQLite that I mentioned a couple of years ago in this post:
Might be relevant.