I’m using RM 10.0.5.0 on an iMac running Sonoma 14.0. In the process of combining two databases, I have a number of small trees that need to be copied manually from one file to the other, using drag and drop. I’ve noticed that about one-third of the time, the copying process adds a single individual to the tree in question.
In a few cases, where I’ve been able to identify the additional person added, it’s a completely blank spouse added to the start person for the tree in question, if that person doesn’t already have a spouse. It’s definitely not a phantom record, as running the “Remove phantom records” tool doesn’t remove any of them.
Does anyone have any ideas as to what’s going on here?
Does the blank spouse have a record number? If not, does the couple comprising the start person and the added spouse have children in the resulting database?
The blank spouse does not have a record number. In the cases I’ve been able to identify, the start person already had children, just no identified spouse.
That sounds normal to me. A child has two biological parents so the database structure is designed accordingly. If one parent is unknown, the box or field in which its name would appear, if known, is blank. The known parent is shown having a blank spouse.
If the start person in their original tree had children, then they would have had a blank spouse there, too.
Well, sort of. Normally, with an unknown spouse, there would be a gray box with a + sign and the words “Add Spouse” with nothing else. But that’s not what I’m seeing. Instead of the gray box, there’s a white box with a silhouette of the most likely gender and the b:, m:, and d: spaces (assuming it’s a missing male spouse). And the copying process is adding one person to the count of the individuals in the tree. That’s how I spotted this in the first place.
Those symptoms suggest that a record has been added to the internal PersonTable but not to the NameTable. There is a RIN but it may not be displayed onscreen because the software is trying to get it along with the name from the NameTable.
So what you have is a nameless person, or, what I’ve called in the past a ‘headless’ person because there is no Name record, not an empty Name record. I’m assuming you cannot edit this person. I’ve seen or anticipated this could happen since RM4 because the database is not designed to maintain referential integrity.
Because you are seeing repeated instances, please follow @rzamor1 request to send a backup of your database with the small trees to Support so they can witness the anomaly and possibly diagnose the cause.
I hadn’t tried editing the headless people before, but it isn’t possible to add a name to them. I can type in a name, but it just disappears as soon as I close the edit person window. I can add facts, and those seem stable. I will be submitting this to Support either tonight or tomorrow. The problem occurs just as readily when copying to an empty file, so at least I need to send a backup of only one database.
When I have a family without knowing the name of the mother, I usually call the unknown person something like wife of or partner of John SMITH or mother of Ann SMITH. Or you can use something like —?— Then when you find the name just replace with the newly found information. Do something similar for the missing father’s name. That would keep the program from doing as people are describing and it makes reports look better.
Thanks for the clear description. That you can add and edit facts other than Name to the headless person is reasonable because they relate only to the PersonTable record. I overstated what could not be done.
I had developed a Delete Phantoms procedure in SQLite that predates the addition of that feature in RM and addressed the headless phantom in it. I’m pretty sure I had seen instances of the headless person back then.
That could be a workaround that might prevent the creation of headless persons but the fact remains that there is a bug in RM that needs to be addressed. Not every user wants to follow your practice and to do so thoroughly requires searching for single parents periodically to apply it. The resulting numbers might be high in some databases, such as one-name studies.
I was able to replicate the problem with RM10.0.5 32-bit on Windows 10. Starting with a nuclear family (husband, wife, 2 kids) that appeared in Count Trees with a population of 4, I added a single father to the Father and a single mother to the Mother - now population=6. Dragged one of the original kids plus everyone in the same tree to a new, empty database. That reported 7 people copied, not 6 - there’s the extra person created - and the Family View has white boxes with no names where the original had gray boxes with the “+Add…” control.
The Family View suggests there must be 8 people in the tree, not 7, but it turns out there is only the one Headless Person added and is spouse to both the original single Father and single Mother. I was able to add an Alternate Name to the Headless Person and then change it to the Primary name. Now the two formerly Phantom spouses took on the same name and the record number is revealed in the two boxes as being the same.
So there is nothing unusual about @CherylC database and the bug is common to both Mac and Windows (32 bit, at least) versions of RM and is repeatable.
Great job Tom in figuring this out–so my question is
As a work around for now to get rid of the headless person , can you unlink him from any kids and spouses-- then delete him? Just a thought as a work around until support can fix it…
Yes, one can right-click on the white box, select “Unlink from spouse” and that seems to cleanly remove the phantom from the tree but it ends up in a new tree of its own. You can go to that tree, right-click on the white box and select Delete and the phantom is gone.
A shorter cut is not to unlink but to directly Delete. In my test case where there was the one phantom linked to two spouses, deleting once cleared both white boxes. That’s faster than unlinking twice, going to the phantom’s tree-of-one and then deleting.
Hmm, in my case the original database has multiple trees and none of the RINs in the tree I started with are boundary, except for one of the added single parents.
yeah, I was not expecting that result. macOS Sequoia 15.5 on M1 MacBook Pro
I just built a new db based on your test case. so the new and old db had only 6 people. I should have some time to test on a db with multiple trees tomorrow.
I just replicated your tree in a new database and did the drag’n’drop of one of the kids with all in the same tree to a new db and got the phantom - 7 people instead of 6.
So it’s not related to age or population or hysteresis in either the original or target database.
And
suggests potential differences in the compilation of the 32-bit and 64-bit Windows versions or different behaviours between Win 10 and Win 11, just as your different result from the OP’s suggests different behaviours between MacOS versions or Mac hardware.
