Jump to content


Photo

TreeSync error with Personal and Family Marriage


  • Please log in to reply
7 replies to this topic

#1 aantiix

aantiix

    Member

  • Members
  • PipPip
  • 10 posts

Posted 26 August 2019 - 06:17 PM

I use the Personal marriage type for women in my family tree in cases where I just need to reference the last name, such as if I am not interested in their spouse and children, but want to make note of their married surname. Another case is when someone is divorce or widowed, them marries into my family. I don't want to record their previous marriage but want to create a fact to document the name change. There seems to be a problem with TreeShare though for the following criteria:

 

Marriage (Personal)

  - Spouse 1

Event

  - Details: Widowed

Marriage (Family)

  - Spouse 2

 

Where Spouse 2 is my blood relative. I can create the facts in RootsMagic, but when I attempt to update Ancestry using TreeShare I get the following error:

 

Access violation at address 0129BB50 in module 'RootsMagic.exe'. Read of address FFFFFFC.

 

I was finally able to add all facts by following these steps:

1) Create Marriage (Personal) in RootsMagic

2) Create Event for Widowed in RootsMagic

3) Create Marriage (Family) on Ancestry

 

It may have worked to create all facts on Ancestry and sync to RootsMagic as well but I didn't try that way. The main point is that it is not possible to create all facts on RootsMagic and sync to Ancestry without getting the error noted above.

 



#2 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6256 posts

Posted 26 August 2019 - 10:00 PM

Have I missed something in my lack of activity? A Marriage (Personal) fact type is not a RM built-in one. While I have seen something that might be characterised as such as a result of a TreeShare download, I've considered it an anomaly in RM's processing of Ancestry's Marriage event which is quasi-personal.

How did you go about creating this fact type and does Ancestry recognise it as a valid Marriage event or just as any custom fact?

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 aantiix

aantiix

    Member

  • Members
  • PipPip
  • 10 posts

Posted 12 September 2019 - 02:12 PM

Marriage exists as for both Family and Personal as default fact types as I know I didn't add this type. The personal fact type is useful when you really don't care about a previous marriage (widowed then married into the family) but you want to track a persons name. In RootsMagic, I add the spouses name in the Description field. On Ancestry it shows as a Marriage along with the relevant information (Date, Place, Place Details and Description), under  Spouses the person in question is just not listed obviously since they are not in the family tree.



#4 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6256 posts

Posted 12 September 2019 - 07:50 PM

To know exactly what the built-in fact types are, create a new empty database and inspect Lists>Fact Type List. You will see but one Marriage fact type and it is the 'Family' type. The Personal type is typically added by a TreeShare download when only one of the people in a Marriage has the Marriage fact. RM people have repeatedly said that Ancestry only has the equivalent of RM's Personal type facts and so the TreeShare process has to convert matching pairs of Ancestry's Marriage events into a single RM Family-type Marriage event. If there is no paired Marriage event, then I suspect RM creates this 'Personal' Marriage fact. Iirc, and it has been years since I first uncovered it, it still points to the builtin 'family' type Marriage fact type but instead of it being related to the 'family', it points to only the one person, as for any other 'Personal" type fact. You have to inspect the tables with SQLite to see what is going on.

 

Personally (pun intended), I think that is a logical inconsistency or discontinuity, if not a bug. RM has built in fact types of both 'family' and 'personal' types for Census and Residence. It shouldn't be using the Marriage 'family' type for 'personal' events.


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.


#5 aantiix

aantiix

    Member

  • Members
  • PipPip
  • 10 posts

Posted 12 September 2019 - 08:56 PM

I guess Im failing to see what your attempting to point out. The family and personal marriage types work exactly as expected in both RootsMagic and Ancestry so there isnt an issue with Ancestey not understanding either type. My bug report was just that when a marriage (personal type) ended, as there isnt anything such as divorce or death tied to that marriage, this causes a problem. I was able to work around it with trial and error. If your reply is just explaining that this isnt something that RootsMagic would investigate for some reason then would help if you clarified that. Because again Ancestry clearly understands both personal and family marriage types entered into RootsMagic, but Treeshare chokes when a second marriage begins without the first ending in some way. Which I guess depending on where you live, could be normal behavior as well.

#6 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8477 posts

Posted 13 September 2019 - 12:46 PM

RootsMagic uses the default Marriage fact when the default individual marriage facts in Ancestry is transferred into RootsMagic. About the only way I see a different individual marriage fact coming from Ancestry is if someone added a custom individual marriage fact there that we couldn't recognize as the default one. 

 

You can tell what facts are default facts in RM. When you Edit them in the Fact Type List the name and abbreviation fields are grayed out. It also won't let you delete them. 


Renee
RootsMagic

#7 aantiix

aantiix

    Member

  • Members
  • PipPip
  • 10 posts

Posted 13 September 2019 - 01:53 PM

I must have been mistaken and had added the personal marriage type in RootsMagic. I never sync'd my tree from Ancestry to RootsMagic as I had used a different app before RootsMagic, so I imported my tree into RootsMagic and uploaded a fresh copy on Ancestry. The fact type is recognized by both RootsMagic and Ancestry, weather I add in RootsMagic and Sync to Ancestry of vice versa, it works as expected (with the one issue stated in my initial post). This type works extremely well for me and fills what, in my opinion, is an otherwise major drawback to only having family type marriages. Again, just my opinion so please lets not debate that here since this is a bug report. Now, if the answer to my bug report is that this is not going to be looked at at any point due to being a custom fact, so be it. However, as a software developer myself, I assume that if nothing else the developers of RootsMagic would want to know about this so they could handle in a more user friendly fashion than by throwing an access violation. 



#8 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6256 posts

Posted 14 September 2019 - 10:10 AM

Two distinct issues have been raised in this discussion:

  1. The 'access violation' error when TreeShare uploading an update of a custom 'personal' RM Marriage fact type as described by aantiix
  2. The incomplete conversion in a TreeShare download of the standard Ancestry 'individual' Marriage event into the standard RM 'family' Marriage when the spouse is missing from the Ancestry Tree, as I described in trying to clarify where aantiix's 'personal' Marriage fact type originated.

I thought I had described how #2 arises in an earlier post but I cannot find it. What I did rediscover was the series I did in Jan 2018 on TreeShare Foibles. In it, there are examples of how Residence facts flip-flopped from 'family' to 'personal' due to a mismatch in labelling between RM and AMT. Not necessarily the same thing.

 

To understand the Marriage (mis-)conversion, a little explanation of the database is necessary. RM uses a SQLite relational database. The FactTypeTable defines fact types. The PersonTable the RIN, unique ID, gender...; NameTable the primary and alternate names for each person; FamilyTable the pairings of RINs that make up each couple; and, finally, for this discussion, the EventTable which records the events for each person or couple (family). Being relational, each EventTable record stores the date(s), description and note for an event and pointers to the FactTypeTable for the event name, sentence template et al; to the PersonTable if it is a 'personal' fact type or to the FamilyTable if it is a 'family' fact type and from these to the NameTable to fetch people's primary names.

 

Here's where the mis-conversion comes in:

  • The FactTypeTable has a column OwnerType which sets the type for the fact: 0=Personal, 1=Family. 
  • However, the EventTable also has a column OwnerType which normally matches the value from the FactTypeTable. My guess is that this was originally done to accelerate certain queries - maybe a holdover from RM3 on xBase and likely unjustifiable with current technology. 
  • If EventTable.OwnerType is 0, then EventTable.OwnerID points directly to PersonTable or even to NameTable to fetch the person's name.
  • If EventTable.OwnerType is 1,then OwnerID points to the FamilyTable and there follows two lookups for the names of both spouses

What I think happens to cause the misconversion is that the AMT Marriage event is (or was) getting stored in the EventTable with OwnerType=0 (personal) under some conditions even though it is related to the standard 'family' Marriage fact type in the FactTypeTable. It's as though the TS import process failed to create a FamilyTable record for the known spouse and the unknown one (RIN=0) and left the OwnerType as 'personal'. This should result in some weird behaviour in a number of editing and outputting processes as the Marriage 'family' type is being used as a 'personal' event. There is no  Problem Search or other detection in RM that I know of.


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.