Sorry just join this thread – to make sure I understand you EXPORTED a GEDCOM from Ancestry and that GEDCOM contained the "_UID"
No, my “sense” is that the user wants to use RootsMagic to land the contents of their Family Historian database and its associated record identifiers (for each individual) up onto Ancestry.com as a tree (ie. use RM to do what FH can’t do on its own).
But, when RM11 imports the GEDCOM (v 5.5 from Family Historian) with its _UID tags, they (the FH record identifiers) are not making their way to Ancestry via the TreeShare API (despite being intact in the PersonTable UniqueID column). To attempt to prove that RootsMagic introduced this new problem, they go one step further and export a GEDCOM down from Ancestry (after the TreeShare UP) and there is no longer record identifiers represented by either _UID or just UID GEDCOM tag(s).
I suggested perhaps because the API for TreeShare UP might have transmitted up the record identifiers in the form of the more common 1 _UID tags, instead of the way Ancestry supposedly deals with them …which is 1 UID (no underscore), thusly making them “not accepted”.
1 Like
No, my “sense” is that the user wants to use RootsMagic to land the contents of their Family Historian database and its associated record identifiers (for each individual) up onto Ancestry.com as a tree (ie. use RM to do what FH can’t do on its own).
Nearly correct - just the tense is wrong.
I have been using RootsMagic to land the contents of my Family Historian database and its associated record identifiers (for each individual) up onto Ancestry.com as a tree since before November 2022 (ie. use RM to do what FH can’t do on its own).
When I started it was in RM8, I bought the upgrade to RM9 and have just bought RM11 upgrade due to the imminent discontinuation of the old api by Ancestry. From other people using the same process I understand it works in RM10.
There are a number of issues that can happen when using TreeShare. E.g. an extra gender record is sometimes added on Ancestry, marriages only have one spouse. A final step is therefore to export the tree from Ancestry and compare it with the RootsMagic tree to look for anything that hasn’t transferred correctly. That is how the issue with missing UIDs was found when I used RM 11 for the first time.
1 Like
A feature of RM which has been there since at least RM 9 and believe earlier versions has been broken by the change to the new Ancestry api.
I’d be grateful for an indication as to whether this is going to be fixed or not. I have an idea on how I can circumvent the problem but it’s going to take a lot of work. I’d rather not expend that effort if the fault in RM 11 is going to be fixed.
I don’t have an answer for you. Development hasn’t determined where the change came from.
1 Like
Not that I expected anything, but TreeShare is still broken in RM 11.2 which was released yesterday.
Given that you brought this issue to light less than a week ago and Renee indicated that development was looking into it, there shouldn’t have been an expectation that it was fixed in..release that was already being fine tuned to fix another problem. I would expect it to be a month or two at the minimum if it is even deemed to be something broken.
As I said, I wasn’t expecting anything but thought there was a chance it may have been a simple omission which was easily fixed. Also as a new update was out I half expected someone to ask if I had tried the new version which was obviously to do with TreeShare issues and therefore I pre-empted the questiion.
I’ve been thinking more about this response:
I’m totally baffled as to how you can come up with such a statement. It has been absolutely proven that something TreeShare has done reliably for years doesn’t work now - it is broken.
The question is are RM inclined to fix it or are they going to leave myself an others who rely on the UID being uploaded struggling to find alternative processes? I’ve been experimenting to find alternative methods of getting the UID in to an existing tree on Ancestry without success. Reloading the tree via a GEDCOM isn’t an option as I’d lose all the linked DNA matches.
No, it doesn’t mean it is broken. It means that your edge case was something that Noone thought to use until you stumbled on it. Due to changes, it became necessary to change something and this impacted you and the 3 other people that might have been using it in the same way. This is much the same as the people using RINs in RM then being shocked that this is not a reliable way to do things because said RINs can, and do, change under certain circumstances.
Also it might NOT be a issue with Roots Magic … It might be a issue with the new Ancestry API, in which case Ancestry will have to fix it (or not).
In my testing I found that the Ancestry GEDCOM download never contained the same UID that we “sent” if we sent one at all. It’s not something that was ever tested or considered earlier. What development needs to determine is if Ancestry ever used it and if the new API doesn’t now use it. The UID appears to be something Ancestry generated on its own from an uploaded tree. Now its behaves like a manually entered tree.
@rzamor1 I don’t know what you are doing with your testing, but your conclusions are wrong.
Ancestry does not have any way of generating it’s own UIDs, there is no way in the interface to see or enter them. They only derive from being present in an imported GEDCOM or uploaded through the API (pre RM 11).
I do not make any changes on Ancestry, everything on Ancestry is uploaded from RM using TreeShare. I started on RM 8 in October 2022, upgraded to RM9 in March 2023 and to RM 11 last week. My main tree has 2830 individuals. 2822 of them have the same UID as in RM, the other 8 have no UID. The 8 without UIDs were added to Ancestry using RM11, the 2822 using RM 8 or 9.
It has occurred to me that you may be being confused by the different formating of UIDs. UIDs may be:
- 36 characters long in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx where x is 0-9A-F
- 32 characters long xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx the same character string with the hyphens dropped
- 36 characters long xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxyyyy where the x’s are the same as above and the y’s are check characters.
Example
The software where the data starts holds the data in GEDCOM 5.5.5 format and has:
0 @I147@ INDI
1 NAME Ann /Winter/
1 SEX F
1 DEAT
2 DATE APR 1726
2 PLAC Aubourn, Lincolnshire, England
1 BURI
2 DATE 27 APR 1726
2 PLAC Aubourn, Lincolnshire, England
1 FAMS @F128@
1 _UID 4B60FBE0-78C3-4A2C-BB94-E14C22AAEE63
The export from there changes it in to the format RM expects so in the GEDCOM file imported in to RM there was:
0 @I147@ INDI
1 NAME Ann /Winter/
1 SEX F
1 DEAT
2 DATE APR 1726
2 PLAC Aubourn, Lincolnshire, England
1 BURI
2 DATE 27 APR 1726
2 PLAC Aubourn, Lincolnshire, England
1 FAMS @F128@
1 _UID 4B60FBE078C34A2CBB94E14C22AAEE63D046
In the RM tables there is:
This person was uploaded to Ancestry using TreeShare in RM 8 or 9.
In the GEDCOM exported from Ancestry it has:
0 @I262428893405@ INDI
1 NAME Ann /Winter/
2 GIVN Ann
2 SURN Winter
1 SEX F
1 FAMS @F398@
1 DEAT
2 DATE Apr 1726
2 PLAC Aubourn, Lincolnshire, England
1 BURI
2 DATE 27 Apr 1726
2 PLAC Aubourn, Lincolnshire, England
1 UID 4B60FBE078C34A2CBB94E14C22AAEE63
So we are seeing the three different formats of UID where the first 32 characters ignoring the hyphens are the same:
- Original source of data: 36 characters with hyphens
- GEDCOM imported in to RM and internal RM database storage: 36 characters including the 4 added checksum characters
- Export from Ancestry: 32 characters - no hyphens or checksums
@rzamor1 Has the above post clarified the issue or do you need more information from me to progress this problem?
It’s been reported to development.
1 Like
I have also been affected by this issue. UniqueID is designed to ensure that individuals are identified unambiguously when data are transferred between different apps, and the current RM / Ancestry exchange appears to be compromised.
RM uses it extensively internally, but doesn’t display it in the normal UI so the majority of users are probably unaware of its existence. It also supports import and export of Unique ID via GEDCOM. Up until two days ago, it was fully supported by TreeShare. Like RM, Ancestry does not display the value, but includes it in a GEDCOM export if available.
With the new API, if I upload my RM tree to Ancestry via TreeShare, all new Unique ID values are missing from the Ancestry GEDCOM export. None of us here can know whether it’s RM or Ancestry that’s mishandling them, but to a user that’s irrelevant. All that matters is that what has worked perfectly since at least RM8 (and probably even RM7) is now broken.
I was going to upgrade to RM11 to maintain access to a fully functional TreeShare (some features are disabled in Essentials), but there’s little incentive to do until this issue is fixed as my current version does everything else I need from it.
Ok, so edge case user #2.
Since Ancestry clearly doesn’t make use of it, RM doesn’t seem to make use of it…nor does any of the other genealogy software that I am familiar with. My question is why is this such a hardship? Sure, the UID appears in in the programs, but isn’t seemingly used.
RM does use UID internally!
If you import a GEDCOM with an individual who has a matching UID to an individual already in the file, AutoMerge with the ShareMerge option on will merge them even if they wouldn’t otherwise be matched, for example if the name has been changed (in that case the different name will be added as an alternative name to the original individual).
The AutoMerge tool explains this:
UIDs are crucial to make this work so that individuals that were in the GEDCOM exported and are in the modified GEDCOM returned are 100% successfully merged no matter what changes have been made.
nor does any of the other genealogy software that I am familiar with
I suspect that may not be true and it’s just that you being unaware of UIDs hadn’t discovered how they are used.
1 Like
Also…
If you had exported a GEDCOM from Ancestry and given it to someone else and they returned the you a modified version of the GEDCOM, you could import it in to RM AutoMerge with the ShareMerge option on and it would reliably merge individuals. You can then upload the changed or added individuals back to Ancestry using TreeShare.
Or you could until RM broke TreeShare uploading the UIDs.
Given how often we see people on Ancestry Facebook groups asking about merging a GEDCOM in to an existing tree I’m suprised that RM haven’t pushed this more as a reason for people to buy RM.
thanks for sharing I had forgotten about those options / features