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
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.