Jump to content


Photo

Tree Share disconnected from Ancestry


  • Please log in to reply
6 replies to this topic

#1 kidhazy

kidhazy

    New Member

  • Members
  • Pip
  • 4 posts

Posted 10 February 2018 - 10:38 PM

I haven't used RootsMagic 7.5.4.0 for a couple of months, and now when I open up my database it appears the connection to Ancestry via Tree Share is disconnected.

 

RootsMagic can log in to my Ancestry account via Tree Share, but then it wants me to either Upload a New Ancestry Tree, or Download an Ancestry Tree.

 

I can manually log into my Ancestry account via a browser.

 

How can I reconnect RootsMagic database to my Ancestry tree.  I don't want to have to reupload everything again.

 

Thanks.



#2 kidhazy

kidhazy

    New Member

  • Members
  • Pip
  • 4 posts

Posted 11 February 2018 - 02:43 AM

So I just found this post that talks about some of the issues with disconnected databases http://forums.rootsm...ted/#entry87237

 

I checked my backups and sure enough a backup still has the connection to Ancestry - but it was from Sept 2017, so lots of things have changed.

 

When I do the file compare as mentioned in the link I find lots of entries that have changed.

 

I couldn't see an easy way to accept/apply all of the changes from the current database back into the old backup.

 

Is there a way to do it, or is it a manual, record-by-record process ?

 

Thanks.



#3 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5876 posts

Posted 11 February 2018 - 05:15 PM

I don't think there is any easy method using RM itself. I would use SQLite to copy the TreeShare links from the September connected database to the latest disonnected descendant of that database. Provided it is a direct descendant and not one created by a drag'n'drop from the earlier, all the people, events and sources that were TS linked in the Sept database and still remain in the current one should become relinked.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#4 kidhazy

kidhazy

    New Member

  • Members
  • Pip
  • 4 posts

Posted 12 February 2018 - 01:16 AM

Thanks Tom.

 

So are you suggesting to copy the entire LinkAncestryTable from the old (working TreeShare database) to the current one, or are there selective indexes or data within that table that I should copy over.

 

If it's copying the entire LinkAncestryTable over what's the best way when using SQLiteSpy?  Any existing SQL I can copy?

 

Thanks.



#5 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5876 posts

Posted 12 February 2018 - 10:37 AM

If the LinkAncestryTable in the later file is empty, then copying over the old one is certainly easy. I cannot say what might happen if there are records in it that point to now non-existent items, ones that you have deleted since the backup.

If you need more help with SQLite to accomplish your goals, perhaps it's better to PM me or follow-up in the SQLite Tools for RootsMagic Wiki.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#6 kidhazy

kidhazy

    New Member

  • Members
  • Pip
  • 4 posts

Posted 13 February 2018 - 05:54 PM

Thanks Tom.   Interestingly when I went into my current database last night the connection to Ancestry was there - but it showed pretty much everyone had changed between RM and Ancestry.

 

I then did a compare of my Sept backup and current file and found I am in a bigger mess - records entered in Sept backup, but not in current file and vice-versa.  Obviously I hadn't been paying attention to where I was adding records.

 

I'll aim to cleanup my database and then re-upload to Ancestry rather than trying to fix.  Thanks.



#7 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3089 posts

Posted 13 February 2018 - 07:42 PM

Sometimes you need to be a little cautious about interpreting the results of comparing databases. You can compare two absolutely identical databases and the compare will usually identify some differences. Or at least that's my experience. When the database compare feature first came out, I did exactly that experiment. Namely, I made an exact copy of my production database and compared the copy against the original. The compare found a very large number of differences between the databases. I have been very suspicious of the database compare feature ever since.

 

Here is what I think is happening. Before the database compare feature came out, RM had (and still has) a feature called Duplicate Search Merge. It ran against just one database, and it tried to find duplicate people in your database. For example, if you had John Doe born 1877 in Missouri and another John Doe born 12 Mar 1878 in Missouri, the Duplicate Search Merge would suggest that perhaps these two John Does were the same person. You would need to make the final determination yourself but Duplicate Search Merge would be making suggestions of things for you to look at. Well, I tend to suspect that RM's compare database feature is not so much comparing two databases as it is running a Duplicate Search Merge across two databases at the same time. So if you had database A and B which were exact copies of each other, the database compare would suggest you look at each of the John Does in database A vs. each of the John Does in database B. That's four different comparisons. And if there are lots of people in your database with similar names and similar birth dates, the the database compare function can easily identify a lot of false differences in what are really identical databases. Or at least that's the way it seems to me, and I could be wrong.

 

There are at least two different ways the database compare could have been programmed to work. If both databases are yours and if both databases were created by RM, then this Duplicate Search Merge logic should not be necessary for comparing databases. That's because RM assigns a unique ID to everyone on your database (the unique ID I'm talking about is not visible to the user interface).  So, if for example, you were comparing Thursday's version of your database against Sunday's version of your database, RM could easily do exact matches between people in the two databases based the unique ID's and could easily tell you exactly where the differences are between the databases.

 

In the other way the database compare could be programmed to work, one of the databases could be yours and the other database could have been created by importing a GEDCOM that your cousin sent you. Even if your cousin were using RM, the unique ID's in his or her database would not match yours, and the only thing the database compare could do would be essentially to do a Duplicate Search Merge type of comparison across both databases. Under these circumstances, you could and often would see a lot of false differences.

 

From observing the behavior of the database compare feature, I think it only works in the Duplicate Search Merge mode, even if both databases are yours and even if both databases are populated with unique ID's that could work across both databases.

 

The existing database compare feature works pretty well for what it works pretty well for (circular, I know), by which I mean that it works pretty well for comparing your data to your cousin's data. I don't think it works at all well for comparing your Thursday data to your Sunday data.  I think the feature needs two improvements. One is that when the unique RM id's exist in both databases, then RM should take advantage of those id's and match based on them. Secondly, if your database has been matched to a tree on ancestry using TreeShare, then RM records a tremendous amount of information about what has been changed and what has not been changed. I think it should be possible to enable this tracking feature even if your database has not been matched to ancestry.

 

There already is a very weak tracking feature in RM - namely the Date Last Edited feature. But it doesn't track what was changed, only when each person was changed. And even within that constraint, the Date Last Edited feature is unreliable. The Date Last Edited field can be updated even when a person hasn't been changed and it can fail to be updated even when a person has  been changed. Therefore, I think it would be totally wonderful if the change tracking in TreeShare became a part of mainstream RM instead of just being a part of TreeShare.

 

Jerry