New Treeshare problem - person acquires a new spouse

I have recently been getting a few access violation errors using Treeshare to transfer data from Ancestry to RM, which is something new for me. (I have had them previously during ‘mixed’ operations, transferring data from Ancestry and deleting other data in it.) This time, immediately after getting the access violation error, I noticed that the person I was working on had acquired a new spouse. (You may notice that there are also a duplicated baptism and departure records, which are not duplicated on Ancestry.)

Not surprisingly, the same spouse shows up in other parts of RM

I can’t think of anything specific or unusual about the circumstances of my use of Treeshare leading up to the access violation error. I was showing all people in Treeshare, not just those changed. The error occurred when I was accepting changes including adding Ms Scrivens’s real husband Alfred Coates and some new events about her - my next step would have been to add their marriage.

I have seen Treeshare fail to add real children before, sometimes adding a phantom child and sometimes another person in the child’s place, but this is the first time I have seen it add an erroneous spouse. The presence of the duplicated events makes me wonder whether the process somehow got duplicated and whether the new spouse was created as part of this duplicated process, in the same way that adding two children with the same name sometimes add a random child to the family.

I made a copy of the file, but stupidly not before running the database tools. (The integrity check did not report any errors.)

(The unfortunate Ms Scrivens married her husband, a Canadian in London in Q1 1941 when she was 19 but he died on 2 March 1941 when his plane went down over the North Sea returning from a raid over Germany)

[Entry edited to note the duplicated fact records and add to my speculation about what might have been going on.]

As a test, I checked to see what happens if you use Treeshare to add two spouses with the same name in the same update operation. (Those who have followed my other Treeshare posts will know that adding two childen with the same name in a single update operation causes corruption in the database, with one of the records partly added.) Of course, the multiple children problem happens frequently in everyday use, whereas the multiple spouses problem is extremely unlikely, but I suspect that it is what happened when I enountered the access violation error described above.

You will see below my test database with the two spouses waiting to be added,

provisionally added but not accepted

and after accepting

Just as with the duplicate children, the end result is that one of the spouses is added properly and the other only added partially. You can see this more clearly after exiting Treeshare

George Dodds has two spouses, one of whom is blank, and only one entry in the couple list.

In the children case, we found that RM did not create a new main person or index record for the second child, but it did add a random ID number to the family table for the parents concerned. For children, I usually see a blank record, like that for the blank spouse, and in other cases see a random child from some other family. I suspect that the former case arises when the random number does not match the RIN of an existing person in the database and that the second case arises when it does match. I also suspect that the same thing happened here. For some reason related to the access violation error, RM tried to duplicate the operations concerned; it successfully duplicate the addition of the fact records but failed on entering the second spouse, creating a new entry in the couples table for the current person and with a random number for her spouse. As this random number matched an existing person’s RIN, she appeared as a new spouse.

I can’t help thinking that RM should use database procedures for this sort of update to ensure that they are completed in their entirety or not at all, and that this would avoid many of the instances of database corruption that users currently encounter.

[Post edited to add more informative image showing corrupt second spouse record.]