Jump to content


Photo

Shared Facts in Ancestry Sync


  • Please log in to reply
10 replies to this topic

#1 michelecolson

michelecolson

    Member

  • Members
  • PipPip
  • 9 posts

Posted 03 February 2019 - 10:31 AM

Hi. I have a research Ancestry tree for a research project that I am working on that is synced to a RM database. These are separate from my main Ancestry tree and my main RM database. Is there any workaround to get shared facts synced to the Ancestry tree? I do not care if they sync as separate facts in Ancestry rather than shared as long as I don't have to enter them separately although I would prefer they stay as shared in RM (not sure if that is even possible). I do not do gedcom except for dna exports and certainly wouldn't do so for this research tree. This tree will never be exported or copied to my main tree in any fashion. 

 

I tried a family fact but that only does it for the married couple. 

 

Thanks, 

 

Michele Colson



#2 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6160 posts

Posted 03 February 2019 - 12:13 PM

RM shared events cannot be related to events in the Ancestry Tree. I developed a process some years ago that converts them to individual events that can be synced with Ancestry. See https://sqlitetoolsf...-to-individual/

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.


#3 michelecolson

michelecolson

    Member

  • Members
  • PipPip
  • 9 posts

Posted 03 February 2019 - 01:29 PM

Thanks so much, Tom. I will give this a try.  :) Any tips on a SQLite manager? I am experienced with Toad for Oracle db (PLSQL) & I work a little bit with SQL Server. Anything similar to Toad would be fantastic - the language seems very similar. I don't mind paying a reasonable fee if it does allow me to export queries to flat files. 



#4 Rick Landrum

Rick Landrum

    Advanced Member

  • Members
  • PipPipPip
  • 318 posts

Posted 03 February 2019 - 02:06 PM

Try SQLite Spy (freeware)


RickL


#5 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6160 posts

Posted 03 February 2019 - 02:11 PM

I don't know Toad. All SQLite managers support SQL queries in the SQLite syntax. Some support a higher level scripting language such as LUA. See https://sqlitetoolsf...sqlitemanagers/

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 michelecolson

michelecolson

    Member

  • Members
  • PipPip
  • 9 posts

Posted 09 February 2019 - 11:26 AM

Thanks, Rick - I'll give SQLite Spy a try. 



#7 michelecolson

michelecolson

    Member

  • Members
  • PipPip
  • 9 posts

Posted 14 February 2019 - 03:16 PM

I tried the script and it worked great. However, I do notice that it creates duplicates when you run it multiple times.

 

I was thinking this might be the best approach: 

1) Run the 1st script to split the shared facts into individual facts. 

2) Run the sync to Ancestry.

3) Run the 3rd script to eliminate the individual facts created with the 1st script. 

 

Then when I have new edits with new shared facts & I re-run the 1st script, there will be no duplicate individual facts. Will that work? 



#8 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6160 posts

Posted 14 February 2019 - 05:25 PM

Yes, my instructions state that script #1 should not be repeated on the same shared events for that very reason.

 

Your sequence sounds valid except for the wrinkles that arise from TreeShare. The scripts were developed long before TreeShare and do not take it into account. I have not examined how splitting shared events, TreeSharing them to Ancestry, deleting them and then regenerating them will work out. Not well, I would expect. All I can suggest is that you try it and find out, using a small database that you can play with and a corresponding Ancestry Tree independent of your main tree. I created a script to copy a group to another database with all the Ancestry linkages, another that disconnects from TreeShare but keeps the linkages for sources and media for the next TreeShare connection. Using those, you could play with a subset of your database.

 

What I think will happen is that you will see on the Ancestry Tree duplication of sources and possibly event media each time you cycle through your sequence. What might work to avoid duplication at either end is some permanent trail of shared events that have been already split that would exclude those shared events from being split again. That would obviate deleting the split events and maintain the TreeShare linkages for their citations and media. Only the newly split events and their citations and media would appear as new in TreeShare.

 

BTW, the scripts do nothing to set a person to the Changed status in TreeShare nor to the Date last edited status in RM.


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.


#9 michelecolson

michelecolson

    Member

  • Members
  • PipPip
  • 9 posts

Posted 14 February 2019 - 08:27 PM

I'll give that a try and see what happens. Thanks for the tips. 



#10 koornalla

koornalla

    Advanced Member

  • Members
  • PipPipPip
  • 54 posts

Posted 18 February 2019 - 06:21 PM

Hi all,

 

I run my primary research on RM and sync to Ancestry and suffer from the same problem as everyone else. Quite separately I export my RM data to GEDCOM and create my own website using GEDSITE. GEDSITE converts the shared facts and they display perfectly on the website. As Tom points out within his utilities page, there are are small number of genealogical programs that either preserve shared facts or convert them,

 

If they can do kit why can't RM/Ancestry do it to?

 

I think our collective focus should be on getting a RM/Ancestry solution rather than workaround that might or might not work.

 

 

Wayne Thurley



#11 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3439 posts

Posted 18 February 2019 - 08:49 PM

GedSite works with GEDCOM created by RM (and also with GEDCOM produced by other software). GedSite does an excellent job of understanding RM's GEDCOM, although most other software does not do so well with RM's GEDCOM.

 

RM's TreeShare works with the ancestry.com API rather than with GEDCOM created by RM. TreeShare can only send things through the API that the API can understand. I don't know the details of the ancestry.com API, but the things the API can understand seems to be strongly influenced by the internal ancestry.com data model which is very different than RM's data model - for example, there are no fact notes in the ancestry.com data model and there are no shared facts in the ancestry.com data model.

 

Of all the things in any genealogy software that seem hard to get changed, getting the fundamental data model changed is surely one of the hardest. It's not the same thing at all (but it's really the same thing), but FamilySearch is another example of a data model that that is seriously inadequate and which I think is extremely unlikely ever to be changed.

 

Despite these limitations, I do think that it would be possible for the RM developers to make some major improvements to TreeShare even using the existing ancestry.com API. But I fear that doing so might require a complete "TreeShare company" with associated developers that's even bigger than the existing RM company itself.

 

Jerry

 

 

P.S. The situation with GedSite and RM's GEDCOM is excellent but it is not perfect. I think that most of the problems are on the RM side of the house - e.g., anything that might get lost with RM's drag and drop will get lost on a RM export of GEDCOM to GedSite. This includes such things as individual customization of sentences and notes for RM's shared facts. Also, RM does not export its default sentence templates for built-in facts (I guess on the theory that if the importing software is RM then the importing software already knows what the default sentence templates for built-in facts are.) GedSite is not completely innocent, either.For example, it does not handle some of RM's sentence template options properly, for example GedSite does not handle Name part options such as :Full and :Nocycle properly (and many of the other Name part options are not handled properly).