Using RM 11. After uploading a RM DB to Ancestry using Treeshare, how do I unlink the DB from that Ancestry Tree?
Let’s say I have DB1 uploaded to Ancestry Tree 1 (Tree1).
I would now like to either upload DB1 to Ancestry Tree2 or, alternatively, upload DB2 to Tree2.
Is this possible? Is there a way to “divorce” a RM DB from Ancestry once the link has been established?
The only published information I can find about Treeshare seems to be from almost ten years ago (2017).
Disconnect from Ancestry Tree:
I don’t think there’s a limit to how many different trees you can share between Ancestry and RM; I have about 7 or 8.
If you have your RM DB1 connected to a tree in Ancestry and a separate (differently named) RM database you can upload the ‘new’ database to a differently named (your choice) database in Ancestry (even if you just put the year after the first DB name). When in RM TreeShare will only update the linked database from/to Ancestry. The other DB will not be affected.
I don’t know from your post if you want the same DB in RM uploaded to 2 different trees in Ancestry. If you do It may be easier to copy your DB on your computer to a different folder and rename the copy. If you load that into RM you can then upload the (copy of the) original DB to a new Ancestry tree. Don’t know why you’d want to do that though.
Here is what happened:
I uploaded my DB to Ancestry and thought all was well. Later, I saw that some people were missing from Ancestry and these same missing people “refused” to upload when I tried uploading them individually. Eventually I was able to upload the missing people but, in the process, it seems many of the people connected to those individuals are not properly linked or have duplicates of their own children. (Only on Ancestry, my RM DB is fine)
At this point I’m looking for the cleanest, safest way to wipe out the Ancestry DB and do a fresh, brand new reload of my DB to Ancestry.
I’m tempted to try the “Reset Tree Share” but I’m not sure what that command does. I want to be sure that command does not affect my RM DB.
Any advice you can offer is greatly appreciated.
Thank you. I’ve never used WebHints. I mistakenly assumed TreeShare was separate from WebHints.
Do you know what the command “Reset Tree Share” does? I assume (hope) that it has no effect on my RM database.
from the F1 Help -
Reset TreeShare - This will cause RootsMagic to rebuild the links to your Ancestry Tree. With a large Ancestry Tree this can take a long time.
Resetting treeshare affects the status of the comparison of your RM db to your ancestry tree - that screen that pops up when you launch teeshare. What’s green, yellow , red, who is in the “changed” list, etc. If you reset the Treeshare link it, that status table has to be rebuilt from scratch.
This problem was reported by several people a few months ago. I don’t recall that a root cause has been determined or that a fix has been reported in any of the subsequent releases, so I suspect that it’s still a concern that you need to look out for. The best test is to compare the number of people in your db with the newly uploaded ancestry tree to make sure that all people transferred.
The RM action that you are looking for is to “disconnect” your ancestry tree, not reset. However, that command is not reversible unless you restore your rm db from a backup. (It’s not only webhints that get affected. If you abandon your ancestry tree, any ancestry hints that you have actioned will be lost and you’ll get all of the ancestry hints over again in the new tree.) So the “disconnect” action should be used with care.
If you are periodically pushing up a tree to ancestry, a safer approach is to make a copy of your RM db, disconnect that copy from ancestry and then push a new tree up to ancestry from the RM db copy. This way, your main RM db and it’s connected ancestry tree aren’t affected. I realize that the scenario you describe is different but I want to emphasize that disconnecting your tree from ancestry is not a trivial action. I suggest following the above steps to push a new “private” tree up to ancestry as a test. If the results are what you want then you can make the copied RM db your master, make the new ancestry tree public, then delete the old ancestry tree. If the results aren’t improved (again, it’s not clear that this problem of some profiles not treesharing properly has been resolved), then you keep your existing RM db and ancestry tree - no harm no foul - just delete the RM db copy and test tree.
Thank you for a very clear analysis.
About Reset:
So, a Reset only audits the two databases and updates their sync status. It will not automatically upload missing people or fix broken or missing links on the Ancestry side. Correct?
About disconnect:
After a disconnect and a reload of a previously “synced” database to a new Ancestry tree, Ancestry will (understandably) start all over pushing hints for the new tree. This would also be true for the new “private” tree you suggested in you post, correct?
About missing people:
Is there evidence that people who are “participants” in shared facts will not upload properly to Ancestry? Some of the people who refused to upload were participants in shared facts, but even after removing those shared events, the people would not upload.
Is there a list of RM specific features or issues that should be cleaned up before pushing a DB to Ancestry? Any items on this list that would silently (no error message) block the person being uploaded?
Thank you.
I like to have plenty of backups just in case. Personally I would firstly back up my RM database and then copy the database to a different folder on my PC. Then rename that copy, maybe just by putting a number at the end of the filename. Open RM and load the new database. You should then be able to upload that new database to form a new Ancestry Tree. If all that works you can then delete the old Ancestry tree. You could, of course, delete the current Ancestry Tree and then re-upload your RM database but I would be concerned that you might just lose what you had in Ancestry. Hope that makes sense. Good luck.
Exactly right.
Correct.
The reason I suggested making the test tree private would be to avoid giving others duplicate hints until you have a tree that has all of the desired people in it. There are many reasons why an initial treeshare of a full rm db might not complete (often it’s server load issues on the ancestry side) and the problem you describe increases the potential for the new tree to also have problems – perhaps more than your existing tree.) So, the idea was to keep all of your existing stuff in place and operational until you’re satisfied that the new tree is what you want.
Not that I am aware of. The shared fact only transfers for the person that the event was added to (sharer vs sharee) but a shared fact should not impact whether or not the person gets uploaded, From what I have seen reported the core issue with whatever changed in the API is not straight forward or intuitive. Here’s a link to another thread from August.. The thread is long but it describes a few scenarios people were experiencing. There are others. This issue is significant enough that it will be called out when the fix is available.
Great question. There’s nothing that should block a person in your DB from being uploaded via Treeshare. There have been requests for such a block (for privacy reasons) but none exists yet. There are settings to block Facts and/or Notes marked private from an initial upload but that won’t affect the uploading of the person record.
The question of features to cleanup before uploading is a good one. I am sure that folks can weigh in with good suggestions from the perspective of data quality. This post is already quite long and others are better qualified to comment. To reiterate, no features should silently block a person from being uploaded via treeshare.
One last thought is that you might consider seeing if the problem is repeatable.. ie do the same people fail every time? if so, opening a support ticket would be a good idea. It may help development isolate the core issue(s). Even if it’s not repeatable to the specific people that fail but it never completes 100%, it could still be helpfull to open a ticket.
It is indeed repeatable. I did a fresh upload from a duplicate RM DB. 39 out of 6812 people fail to upload. Many (perhaps all) of these 39 are the same folks I had trouble with on the first upload.
I guess I will try opening a ticket tp see if it leads anywhere.
