Jump to content


Census (Family) and Residence (Family) fact type problems

census residence family

  • Please log in to reply
20 replies to this topic

#21 Vyger


    Advanced Member

  • Members
  • PipPipPip
  • 3443 posts

Posted 23 November 2019 - 01:29 PM

mjashby is right. The Census (fam) and Residence (fam) events that you see with no spouse in RM are due to a shortcoming or bug in the interface between RM and Ancestry. These RM (fam) fact types remain coupled when uploaded to Ancestry (i.e., you see the spouse with the fact in the Ancestry Member Tree) but when downloaded to RM, they become uncoupled. RM relates to them as a (fam) fact type but operates on them as an Individual fact type. Its event record points to the Residence (fam) fact type definition but characterises it as an (indiv) fact type so it is tied to the Person, not the Couple (family). That's why the name Residence (fam) appears (from the definition) and the default sentence has [couple] which can't retrieve the names because the event points to the Person, not the Family (couple). You could safely change the Fact Type in RM from (fam) to (indiv) one by one in Edit Person > Tools or en masse using SQLite:

UPDATE EventTable
SET EventType = 18 -- Census
WHERE EventType = 311 -- Census (fam)
AND OwnerType = 0 -- Person
UPDATE EventTable
SET EventType = 29 -- Residence
WHERE EventType = 310 -- Residence (fam) 
AND OwnerType = 0 -- Person

However, you then have the challenge of propagating those changes back to Ancestry. I would say that RM will come up with a fix to properly handle what Ancestry somehow knows are coupled events and must surely transmit sufficient information through its API for RM to understand that. If not, then FTM2017 must have to confront the same issue and it would be unworkable for everybody. 


Migration, migration, where would we be without it :D


That simple code works well for a bug issue but only works on the principle and not the spouse if you were trying to convert RM Family Facts such as Census and Residence where the OwnerType is "1" to individual facts.

To maintain data integrity is such cases an Event needs to be inserted into the event table but this time using the Father and Mother IDs as the owner id, otherwise they will be dropped.


Just an FYI.

Customers should never be frustrated by things they cannot do.


User of Family Historian 6.2.7, Rootsmagic 7.6.2, Family Tree Maker 2014 & Legacy 7.5


Excel to Gedcom conversion - simple getting started tutorials here