Family Listing View - Unknown Spouses

A new ‘issue’ which seems to have cropped up recently.
A number of Families include an unknown spouse, usually because the parentage of an illegitimate child is not verifiable.
In the Family listing view, the missing spouse was indicated as [Unknown],[Unknown]. The program now seems to be assigning a random Given name so it now appears in the list as [Unknown], randomname. The random name is always the same and appears to be a Surname from elsewhere in the tree.

The convention for unknown used to be [–?–] and you will still find some genealogy articles that recommend this. Nowadays I leave the field blank which seems to be the recommendation in computerised databases (some will disagree). That aside, I still have quite a lot of [–?–] entries which I haven’t changed and I have not seen the assignation of a random Given name that you describe for any of my entries.

This issue was discussed under a previous topic “unknown spouses - who wants them?”. I assert that it is the result of RM8 glitching during data entry that leaves the unexpected name in a record in the NameTable associated with a person record number (RIN) =0. See

So for the non-SQLite users, how can we get rid of that phantom name so that Unknown Spouses show up as [UNKNOWN],[UNKNOWN] again in the Couples listings?

For unknown people, I typically insert the given name as a relationship to the known person. For instance, I would insert [wife of John Doe] as the given name and “Unknown” as a surname would be used for an unknown spouse. That helps me to quickly identify an unknown person in the index and their relationship. The same can be done for children such as [child of John Doe]. When creating reports, I change the name for those to something like “the unknown wife of John Doe”.

I had this problem, most likely caused by corruption in the database. The advice was to drag and drop to a new rmtree. In the event I exported the whole file as a GEDCOM and re-imported it into a new tree , which solved problem for me.

  1. Persuade the developers to incorporate the needed cleanup of the NameTable in their Delete Phantoms database tool and apply it.
  2. Absent that, drag’n’drop everyone and everything to a new database as, no doubt, Tech Support will advise you to do but beware of the collateral losses…
    GEDCOM & DnD transfer losses #gedcom – SQLite Tools for RootsMagic

Thanks for the responses.

Looking at them, the side effects of the ‘solution’ might be considerably more bother than the original problem, given there are only a small handful of cases. As a workaround I have now set up individual records for each ‘unknown’ father with [Father of XYZ] as given name and a blank surname, which puts them at the head of any lists, as they would have been previously.

Talk of ‘database corruption’ is always a bit unsettling, let’s hope it is not manifested in other less avoidable ways.

I usually use “mrs Given Last” for the name of an unknown wife (frequently an earlier wife). If I have siblings with unknown parents - it happens occasionally - it’s “mr Last” and “mrs Last”.

But you can’t be sure that the problem won’t escalate. I started with only one occurrence of it, and then a second appeared. It was at that point that I decided that something needed to be done.
After I did the GEDCOM export/import I had two problems - I lost my Groups and the last edit date defaulted to the date of the import (this problem has been corrected in the latest update, I think).

I’ve now bitten the bullet and done this too.
The major ‘loss’ has been the Groups information, which has been relatively laborious to recreate, as there seems to be no easy way to select or list those individuals NOT linked to any Group. Repeatedly scrolling through Pedigree, Descendant and other views trying to find them also seems sooner or later to provoke Exception errors and a need to restart the program. Given that things like Colour coding and Weblinks are preserved on a Gedcom database rebuild it seems pretty odd that this one isn’t too.