Unknown spouses - who wants them?

Hi, Paul here from Ireland. I am new to RM , so apologies but i am plagued with unknown spouses and they refuse to go away, my dad has 3 and my mom 2. Sometimes young children have one. I also have some double names which are identical, I try to delete one of them, and both vanish, try to rename one, both get renamed. This clearly has affected other people. Could someone in the know please explain in simple terms how to sort this out, step by step. I find I am spending more time trying to fix this than I am producing productive work


Hi Paul! First for duplicates, in your General Settings, set “number to display” to RIN. This is an internal number set by RM for people. If the duplicate name you see has the same RIN, it is likely an alternate name for the same person. If they are different RIN’s but identical information, the best option is to merge, not delete.
Second, unknown spouses. This can be a result of having downloaded people from a website like Ancestry. Running the database tools can take care of this (see clean phantom records). If this doesn’t clean them up look at how the family group is linked. Particularly how a child is linked to its parents. If a child is linked to only one parent, then a placeholder entry is put in place of the “unknown” other parent. To correct this, link in the “known” parent to the child.

Thanks for quick response, am going into battle!

I have a question for alainemk. How do you create a placeholder entry for an unknown parent? Thank you so much for any help you can give me.

If I have duplicate children in a list for a family, I first write down the record number the program assigns for the duplicated child. Then I click unlink from parents which will remove both instances of the name which has the same record number in the list. Then relink the child to the family using the record number.

You can do something similar where different children are listed to only one of the parents and you have both parents in the database linked together. Again write down the record number of the child with the one parent, then unlink from that single parent. Then go to the instance with both parents and add the child.

Terri, RootsMagic creates a placeholder entry in the background that you see as “unknown spouse”. This entry has no record number and cannot be deleted.

1 Like

Indeed @alainemk , unknown spouse with no RIN cannot be deleted. File/Tools/Clean Phantom Records did not remove this ghost wife either.

But I have successfully removed her using her 3 dots menu as shown:

No idea whether that unlinked remnant is floating somewhere, or perhaps that’s what Phantom Clean will now deal with. But at least it doesnt show on the tree anymore.

1 Like

Yes, running the data base tools in order should take care of it as it looks as if no child is linked to Nathan only.

The only record in the database when there is an Unknown spouse (RIN=0) is indeed the link record, provided there are no children. Unlinking deletes that record from the FamilyTable but the children, if any, would lose their other parent unless linked to him through another couple (family). No need to run the DB Tools to clean up.

1 Like

Thank you. I’ll give it a try.

Since I updated to 8.1.3 I have been having a very odd problem when adding someone for whom I know only one parent, usually the father. It seems to be vaguely related to this thread.

Before updating to 8.1.3 I just got an Unknown Spouse, unnamed, RIN 0, as described by others, which was OK, though personally I’d rather it didn’t. Now it is adding a name that is already in the database (the same one each time), but with the RIN 0. In all the cases that have happened so far the sex of this spurious parent has also been incorrect (male, not female). All attempts to unlink this spurious parent in the normal way fail.
Is this happening to anyone else? If so, how have you handled it? The only way I have found for avoiding this seems to be by putting in my own placeholder, which I would prefer not to do.

I just added a Father only to a person. In that person’s Parents view in the sidebar, I see the Mother area is empty but for the sex “(m. )” and the male silhouette. The non-person Mother did not get the name of someone else. Also using 8.1.3 on Win 10.

In this case, I would run the Database Tools to see if it might clear the Name error. If not, you have a repeatable error that is worth submitting a support request along with your database to Support.

I had intended trying to avoid it happening in future with my clumsy workaround, but
I think I’ll take your advice next time it happens so that I have something concrete to show to Support.

I compounded the error initially by not noticing that the sex had defaulted to male - but that surely shouldn’t happen anyway if you’re attempting to enter a mother? So it looks like two problems.

I now think that the problem may not be 8.1.3-related but has been caused, coincidentally, by a record I added to my database on 2 December, the day before I updated to 8.1.3. What attracted my attention was that the name of the intrusive parent was the same in every case, suggesting that that specific record was the source of the problem, not the program.
But I need to do more investigating …

Actually, the (m.) stands for "marriage’ [date]!

Heh! Caught me out, too. But the silhouette is male and that would be uncommon. Better that it be a question mark since the Spouse is unknown.

1 Like

Having identified the records added/edited between 2 and 7 December, I restored my database to where it was on 1 December, and am re-entering them it to bring the database back to its 7 December state.
I am being extremely cautious when adding parents, and so far no problems. I am more than ever convinced that the problem was one of my own making - I goofed somewhere when adding a parent record, and that resulted in some sort of corruption in the database that caused my problem. But I won’t know for certain till I have re-entered all the data.
If I’m right, though, It is perhaps a little worrying that the Database Tools apparently neither identified nor corrected the problem.

That got me thinking and reminded me that RM’s Delete Phantoms does not clean out orphaned records from all tables in the database. Given RM8’s propensity to freeze, crash, or throw an error, it’s possible that a process such as adding a person might not have finished properly. At minimum, 1 record needs to be added to each of the NameTable and the PersonTable. The latter’s PersonID must match the former’s OwnerID. If the NameTable record got added first, the OwnerID might be 0 initially awaiting an update from the process of adding a record to the PersonTable. A disruption between those steps could leave the Name record with a RIN of 0 as its OwnerID in which case all the default placeholder spouses could get that name.

One would have to look at the NameTable with SQLite to find a NameTable record with OwnerID =0 and delete it.

This is way beyond my capabilities I’m afraid.
It’s been suggested to me in the User Group that I should send the details to Technical Support for information, and possibly include a copy of my database.
I will probably do that - just as soon as I can devise a clear account of what I think may have happened!

My theory DOES hold water. I tried creating a phantom spouse name with RIN=0 in the NameTable using SQLite. However, it took closing and reopening the database in RM8 to see the effect I surmised I would see.

I added only one record to the NameTable with the name “*Phantom, Fake” and set its OwnerID to 0. The name does not come out in all screens because the program substitutes “Unknown spouse” in some. Were it to do so consistently, you would be unaware of the phantom name but its existence might be a trigger for some other unwanted behaviour.

I would still submit your database to Support along with your explanation of what you observed and a link to this post. You may not be able to recreate the issue but it would be helpful to others if Support has already analyzed it and can correct the data, even if they, too, cannot replicate the actions that caused it in the first place.

1 Like