I was affected by that bug that caused changes in RM to be lost after creating a relationship chart. My normal sequence of work was to add people to RM, then to copy them to Ancestry using TreeShare, and to log off some time after that. As a result of the bug, these people were lost in RM, but they must still be in Ancestry. Is there a way for me to migrate these Ancestry records to RM? I’ve seen mention of Ancestry hints, but from what I can tell they give you hints for people who are in both databases. My objective is to copy the missing people from Ancestry to RM. Any suggestions?
Run TreeShare again and select the option “Showed Changes”. Now you will see the ones on Ancestry that aren’t in your database. Select them to be put in RM.
Thank you MadDog. The only problem is that I have “Only show changed people” checked yet no entries show up. I know it’s working as it should because yesterday I made some changes in RM and they then showed up as changes that needed to be applied to Ancestry.
Two possibilities: Either my memory of the period when the relationship-chart bug was active is wrong, or else TreeShare was using the permanent version of the database, not the temporary copy created by the relationship chart. I suppose it doesn’t matter at this point - it’s clear there’s nothing now in Ancestry that isn’t in RM. Thank you again for your answer.
Great.
You can download from Ancestry into a new named database, then look at the # of people, etc to see if they are the same. Then delete the new database.
That’s a reasonable supposition. Thinking back to the problem Do not use Relationship Chart until next update else lose data, I would add that RM might be opening and closing multiple instances of its SQLite database engine concurrently and that might be okay because a sqlite database allows multiple readers. But it is supposed to restrict writers to one at a time. I would have expected that the Relationship Charts instance having an incomplete Transaction would disallow any other instance from writing to the on-drive database and that would have prevented TreeShare’s instance of sqlite from writing anything to the database which I think would have to happen if a change is applied in either direction. Maybe the write lock is not applied when the transaction begins but waits until it is committed. Maybe @kevinbenson could clarify what is allowed by sqlite although maybe this is getting too techie for this forum.
I’m wholly unqualified to pontificate on that problem’s potential to have resulted in the actual loss of people. What @TomH has commented about sounds like a pretty spot on deduction one could make. I would only add that we lack any understanding of the particular programming approach the authors use(d) and the separation of concerns assigned to the source language (Delphi is Pascal in a framework) versus the API routines that invoke SQL operations. I know WAL mode allows a way around the writer blocking all readers and the aim that no corruption should occur under SQLite’s ACID properties, to ensure data integrity, rely upon the premise of having the whole of the data between those two non-volatile storage files (.WAL and actual database file) during commits and checkpointing. Whether that was their approach, we do not know. Without that secondary non-volatile store of the data remaining uncompromised, then there’s the possibility of corruption while writing to the one and only permanent file, the database.
1 Like
I think this is the best idea I have seen to address the possible loss of data in RM where the data might yet still be in Ancestry. I would go beyond just looking at the number of people to comparing the two RM databases after you have downloaded from Ancestry to a new and second RM database.
I don’t use TreeShare for anything but hints, so it’s been a long time since I have studied TreeShare in detail. But I don’t think the comparison that TreeShare makes between RM and Ancestry does quite what it might seem to do. Which is to say, I don’t think it compares all the data in RM with all the data in Ancestry to identify the differences. Rather, I think it restricts itself to comparing people who have recent change dates. I’m really fuzzy on the details, and maybe somebody who uses TreeShare more heavily than I do could address the issue. But I think that unless people are viewed by TreeShare as recently changed that differences between RM and Ancestry will not be identified even when such differences exist.
High praise from you, thanks.
I was thinking of Compare but wanted to use KISS method. If the #s were off then Compare for sure.
Also the Date Edited would be helpful except for the fact that downloading a new Ancestry will have the current date for everyone.
I always enjoy your thorough responses.