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.
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.
I really appreciate the time you’ve spent on this and your advice. I will do as you suggest and include link to this thread when I contact support, which is likely to be early next week
Really disappointed to report that yesterday this problem reappeared in my main tree, and while I assume that I did something to cause it, I now can’t for the life of me work out what it was. It seems to be an intermittent problem which I’m assuming is operator error. I haven’t been able to recreate it in my play tree, which is behaving normally so far.
I hadn’t got around to reporting it (maybe just as well), but will do so now. In the meantime my work-around is not to add parents unless I know the name(s) of both.
It may not be any repeatable actions on your part but rather an internal irregular delay in combination with your normal procedure that trips up a sequence in the program giving rise to the orphaned Name.
Trying to devise a form of words for the report I want to send to Support - it really is quite difficult to explain the problem clearly.
Still, at least I have a screen shot now
Finally emailed Support today about this problem. Included the link to this thread, as you suggested.
Thanks again for your help.
Just to bring you up to date - advice was to Drag and Drop, but I ended up simply doing a GEDCOM export and re-import, which solved the problem for me.
Typical response from Tech Support. Clears your problem but they don’t advise you of the potential losses involved nor make any attempt to diagnose the fault and try to determine the cause. See
Thanks Tom. I had already found that Groups didn’t travel, but will read your page on transfer losses carefully so I know what else to expect.
In one way I’m just so grateful that the main body of the database is back and working properly that I can put up with the hassle of having to re-enter some of the data - I still have the corrupted file to copy from (manually, of course!) if I have to.
This problem reappeared today - I could scream! However, at present, it doesn’t seem to be as pervasive as the previous occasion - seems to be limited to just one family, and if that’s the case, I think I know what happened.
Still annoying though