I just did a brief comparison between RM7 and RM9 for a person who has a note in RM which uses hard returns. The note loses all its hard returns in Ancestry. RM7 reports that the note is different between RM7 and Ancestry. RM9 reports that the note is the same between RM9 and Ancestry.
Thank you for that Renee.
I’ve had a quick look at your two database files with SQLite and see the following (I’ll call your original file “CTL” and your TreeShared one “TST” for brevity:
- CTL has 8 records in the PersonTable numbered 1-8; 6 records in the ChildTable numbered 1, 4-8. These numbers are the RIN of each person. 2&3 are the parents.
- TST has 7 records in PersonTable numbered 2-8; 6 records still in ChildTable, numbered 4-8 AND 441 all belonging to the one set of parents (family). There is no PersonTable nor NameTable record for #1 or #441.
For years, I’ve complained that RM is unthorough at cleaning up detritus from deletions and merges (which cause deletions). That did lead to an addition to the database tools, “Delete phantoms” which predates TreeShare. RM does not employ any of the SQLite capabilities to maintain referential integrity; the application is fully responsible for that. So I followed your steps to see what happens along the way:
- After TreeShare upload and then deleting all the children, all the critical tables look good, including the AncestryTable; RM cleaned up appropriately.
- After adding all the children via TreeShare, I get the same result as your TST file with the exception that the strange ChildID is 553, not 441. Let’s call this file TST2.
- I would add that both TST2 and TST have the number 500 in the ChildTable.ChildOrder field for all children after download from TreeShare which may be a flag set by the application to represent that the record order is that received from Ancestry.
Then I checked a fresh download (TST3) of the Ancestry Tree and was surprised by:
- All 6 children transferred intact - there was no blank in the Family View. All critical tables looked normal.
- There is a puzzling difference in the AncestryTable between TST2 and TST3: TST3 has a link for each of all 8 persons while TST2 is missing one for RIN #1 (as noted earlier for TST)
- TST2 has no AncestryTable.anVersion value for the parents RINs 2,3 while TST3 does.
So I think we can safely say that this problem is not a classic detritus issue but something going wrong in the TreeShare update procedure and it fails to replicate the result of a fresh download. That the error is perfectly repeatable augurs well for it to be corrected.
1 Like
Thanks for that useful detail.
Most of the items I see that appear to need updating in RM7 relate to sources, although I do not claim to have made a thorough analysis. I have just updated this person on Treeshare, and yet the Name field still shows that it needs updating.
The detailed update screen shows four new name sources to be transferred, and you can indeed see from the screen print that there are sources by the name in Ancestry but not in RM.
After updating the same person in RM9, I have sources by both the RM and Ancestry names, and nothing new still requiring an update.
The following picture is slightly different but appears to illustrate the same problem.
You will see that there are sources by the person in RM and not in Ancestry and by the name in Ancestry and not in RM. I remember an explanation by RM of this sort of issue saying that it was because of data model differences and that they were looking for ways to fix it.
In RM9, the sources all appear by the name rather than the person, and this does indeed seem to have fixed the problem.
The person in the following image also does not appear on the ‘changed list’ in RM7 and has the problem described above. When you look at her detail page, the entry for the 1860 US census also seems to need updating. The detailed changes screen shows one new source to add to Ancestry and one new source to add to RM. Comparing the sources, they are already the same
Going through the update process clears the item, but I am not sure why it was there in the first place. It was not there in RM9 (and this is after parallel run processing).
I have not tested a note, but your explanation of them is very clear and logical. Taking these sources and notes issues together, RM9 really does seem to have improved the situation over RM7 as regards these items very significantly.
Alan
Thanks for that Tom.
I should perhaps have added that the problem does not affect the new download of trees. No doubt this uses a different process.
RM support have confirmed that they can see the issue and are analysing it.
Alan
1 Like
One of the other points mentioned in my original post was about phantom updates. These are people who appear in Treeshare as having been changed even though no data relevant to Treeshare has been changed.
I have just processed a batch of updates to RM9 reflecting people that I had added or updated on Ancestry. After that I went through the new people and matched them to FamilySearch. In the process, I discovered one spouse that FS had which I had originally missed; I added Mary Beatrice Link to Ancestry, so that she and her husband (Allen Grierson Knapp) are legitimate changes. All the other ‘changed’ people in this screen print are phantom changes caused by RM9.
As I wrote originally the issue arises when you use the ‘Share data’ screen for someone already matched to FS to match their relatives. These relatives do not appear as phantom matches, but the person whose screen you were using when you did the match does.
I think that this is a bug and should be put on the list to be fixed. Plainly, it is much less serious than a bug which results in corrupt data, so would have a much lower priority.
Even so, it is 100% reproduceable. Update everything in Treeshare, match to FS using the ‘share data screen’ for people already matched and don’t change anything else. Go back into Treeshare. I encourage others to test it.
By the way, I made a separate post here about matching people between RM and FamilySearch. As I am now doing this in a parallel run between RM7 and RM9, I can confirm that the RM9 process is much, much more time consuming than that in RM7. This is the main thing I can think of that would prompt me to stay with RM7 as my main database.
One of the points that would fix this (an optional automatic match when hints found) would solve part of the problem. The other part is that scrolling in the RM9 screen is much too slow and that the screen refreshes (taking ages) each time you match someone. This does not happen in RM7.
This is the same Treeshare screen in RM7.
The same two entries in it are genuine. There are many fewer phantom changes because the auto-matching does not generate them.
Alan
A small PS after originally posting this. Because of fact that many items appear to need amending on RM7 Treeshare’s compare person screen and not on RM9, it was relatively painless to clear the phantom changes above from RM9; most of them showed no changes required and just needed a single click. There were, however, a couple of exceptions like this
These show extra sources in RM which is a little odd as I have done literally nothing in this RM database except create and update it from Treeshare, match it to FS, add some colour coding and a group and process a few not-a-problem entries. In this particular case, the source concerned behaved very strangely in Ancestry and did not originally add to the event concerned (the marriage); I had to add it manually. RM shows it as attached twice. I strongly suspect that Ancestry is at fault here.
Manually merging two people does not create any changed people in Treeshare (in either RM7 or RM9). I think that this is a bug and should be added to the list to be fixed. Merging people in Ancestry creates two changed people.
I know that Treeshare is not going to be able to replicate the merge, but it is important to be able to see if the number of people on the two sides differs and to check that the details of the merged people agree.
Alan