These three screenshots of TreeShare Compare in sequence illustrate to me that RM 8.1.8.0 does not correctly transmit or interpret data via the Ancestry API after running the function ‘Merge all duplicate citations’. It’s fairly well known that it can incorrectly merge citations that have differing images or web tags but this is something else. My observation arises from having developed a procedure to import a RM8 database into RM7 and witnessing the surprising result that its citations converted from RM8’s ‘uses’ do match the Ancestry Sources on the Ancestry Tree from which the RM8 database (#1) originated.
If I can create the TreeShare links for duplicate citations in RM7 from the TreeShare link for the ‘master’ citation in RM8 and TreeShare Compare says that they match the Ancestry Sources but the merged RM8 TreeShare shows they are mismatches, then there has to be a problem with how RM8 is comparing the citations.
There’s a second oft-discussed issue with TreeShare having to do with citations for Marriages. Image #1, immediately after TreeShare download to create the database, shows a mismatch. But by the time the data has migrated through merge citations and then imported to RM7, no mismatch!
The procedure I use for the import/conversion from RM8 to RM7 is a SQLite script attached to:
Thank you for such a clear exposition of the problems with RM8 and Treeshare. I use Ancestry extensively and dealing with these mismatches is a daily occurence and something that I didn’t personally encounter under RM7. I only hope that sometime in the near future Treeshate will get the upgade it clearly needs.
Appreciate the work you have done which confirms there is an issue with RM8 TreeShare. I would add that this issue only became apparent to me subsequent to the 8.1.8 update back in March.
I suspect this is related to a change that occurred with the 8.1.7 release that impacted the way that sources and citations are sent to ancestry via treeshare. According to RM support a change was made to treeshare in 8.1.7 to fix an issue that sources were not uploading for some users. That change also impacts how ancestry views sources sent from RM via treeshare if the RM file has been disconnected and then a new tree is uploaded to ancestry. Hopefully a fix is part of the next update or one soon thereafter.
We had to change which source/citation ID we were sending. It’s best to upload the Ancestry tree in TreeShare after you have merged all you sources and citations.
This makes no sense to me. Ancestry does not care what RM’s (or FTM’s) Source/Citation IDs might be. It only recognises the Ancestry ID (anID). To compare a person’s sources between RM and Ancestry requires RM to receive the sources’ textual fields from Ancestry with the textual fields from RM’s sources for that person’s facts. Maybe also factored into the comparison is whether the anID for the sources on Ancestry match those recorded by TreeShare in the RM AncestryTable. On the client side, the program can change CitationIDs at will with no adverse effect on TreeShare Compare as long as the AncestryTable’s field containing the CitationID is kept in sync. Viz what I did to convert RM8 Citations to RM7. All CitationIDs are different but TreeShare Compare shows that the RM7 Citations are the same as the Ancestry sources despite the merging in RM8 and conversion. That also proves that the RM8 merging kept the anIDs synced with the changing CitationIDs. Neither the Ancestry Sources data nor the RM citations data has changed through those crosslinking transformations. So why does RM8 TreeShare Compare declare that the sources are different? Is it looking at RM citations a little differently than other parts of the program? Something amiss with the way it pulls the textual data for reused citations versus the original use?
I think I’ve just proved that it’s not the textual data but a failure to transmit the Ancestry ID of a citation that is reused with this sequence:
I added a Baptism event in RM 8.1.8 and pasted the 1910 Census Ancestry Source citation from Birth with the ‘paste reuse’ option. Then, in TreeShare, added the new fact to the Ancestry person. But the Ancestry Source for Baptism was transformed to an ‘Other Source’.
That says to me that RM 8.1.8 failed to transmit the anID of the Ancestry Source associated with the original citation which was reused. The fault lies in the RM 8.1.8 TreeShare procedure.
I took up the earlier suggestion and uploaded a small (4k people) test database to Ancestry after merging sources and citations. Needless to say as far as I can tell all my previous ‘Ancestry’ sources have become ‘Other’ and Ancestry is showing them as new hints and in addition I still getting the odd marriage pink entries.
Now surely if I was to update my Ancestry tree with the Ancestry hints and then use Treeshare the whole wretched cycle would start again and pink entries would appear right,left and centre.
The latest work by TomH clearly shows that there is problem to be solved but I think for now I will continue with my unmerged citations and ignore the pink matrriage changes.However it is rather annoying that something that worked pretty well in RM7, Treeshare, is causing problems in RM8
Update 8.2.0 does not address the above issues with Merge all Duplicate Citations but does change the behaviour when an Ancestry Source Citation is ‘paste reused’ and updated to Ancestry. TreeShare Compare reports a match and, indeed, on the Ancestry side it is an Ancestry Source. However, it is a duplicate of the Ancestry Source for that same person from which it was copied. The original is linked to the original events; the duplicate is linked to the new event.
