I’m using RM10 on a Mac and I’ve run into into a strange problem. I’m copying groups of people from DB2 to DB1. To avoid creating a merging nightmare, I’m copying family groups over, the number of individuals ranging from 5 to 1,000 or so depending on circumstances. But the copying process, from DB2 to DB1, is creating relationships that don’t exist in either database, generally in the form of an extra set of parents attached to an individual. Sometimes these “parents” are entirely unrelated to each other, sometimes they are siblings. What is causing this, and is there any way I can prevent it? Running the database tools doesn’t identify any problems and fortunately I’m making frequent backups.
1 Like
How are you doing the copy? I’m guessing you are using drag and drop, but you also might be using GEDCOM.
1 Like
Like @thejerrybryan I was was wondering how you were bring people over – sounds like the method you are using may be creating duplicate people and/or missing relationships. also more work in the long run from the sounds of things.
One piece of advice for avoiding creating a merging nightmare is copying from sourceDB to newDB (first). For each drag, then commence normalizing all Place Names and other “conventions” to match the eventual destinationDB.
@CherylC anytime you drop n drag a person from one database to another, you have to MAKE SURE you check the box at the bottom that says is this person the child/ spouse of …
But IF you already have Dad and a child in the other database ( or the parents with other siblings), you have to MAKE SURE you are on the RIGHT page in the receiving database meaning if you have a child and 1 parent-- I would be on the page with the child and parent-- if instead I am on the page where the hubby is the child of his parents and add the spouse there, it will add a 2nd marriage…
As for moving large groups of people, NOT sure you can totally eliminate extra relationships IF some of these people EXIST already in the receiving database-- the problem being that RM for some reason can NOT always determine that the EXISTING and new person are the same or that the child Joe is a full sibling to children Mark and Sue already in database.
You can move a group of people-- then go to the Couple List View and check for duplicate marriages and you can use edit from there to check the info BUT have to go to their main page to correct the fact …
As for kids , it’s harder to identify them-- you will catch some by doing search and using the criteria more than 1 set of parents-- think using Compare database is the best answer
I’ll try to answer all questions at once. Yes, I’m using drag and drop. I’m always careful to check the box at the bottom of the screen re Silly Wench. In any case, this never happens with respect to Silly Wench herself, but with one or more of her descendants. I’m always using the “descendants and their spouses” option. The drag and drop isn’t creating duplicate people (except in DB1 to some extent), just relationships that didn’t exist in DB2. The individuals added as duplicate parents from DB2 always seem to be a pair of sequentially numbered individuals. In the picture I’ve uploaded, they are 4th cousins once removed but with RINs 13494 and 13495 in DB2. I’ve noticed, since I’ve restored from a backup a few times, that the same individuals from DB2 seem to be added to the same individuals in DB1 as an extra set of parents. So whatever is going on, at least it’s consistent.
As far as RIN#, I am sure you already realize that those will change during a drop n drag-- they will also change if you drop and drag a whole database to a new file…
Please elaborate on this–are you saying that every time you have an issue, they are added to the EXACT same 2 people ( who would be the extra parents)? or what?
The last three times I’ve done a drag and drop with the same group of people (after restoring from a backup), the identical individuals from DB2 are added as extra parents to the same individual in DB1. To the best of my recollection, the DB2 individuals have sequential RINs in DB2 and are usually related to each other but are usually not related to the DB1 individual they end up attached to. None of these unusual relationships exist in DB2; they are being created solely by the copying process.
1 Like
The interesting thing here is that the drag and drop in RM10 is new. It now copies directly from database to database. Previously,drag and drop did a GEDCOM export/import. I can’t picture what is going on, but I would be looking at the new drag and drop.
1 Like
Good point- make it an iterative process where the first several drags are disasters but they get better each time with work.
(I hope I’m interpreting your comment correctly.)
1 Like
Yes, less data to work with (in newDB) for potential normalization (versus full dataset of destinationDB) means less to search&compare (thrash) against and hopefully less chance for error (or oversight) …all the while, separate manual-typed work in destinationDB can continue unfettered until any final drag’N’drop normalized merge can arrive to destinationDB.
If you can recreate this with the same people open a support ticket with the steps and databases for testing.
https://support.rootsmagic.com/hc/en-us/requests/new
I did that, and received a reply telling me how to unlink the extra parents. I hope that’s just an interim response.
There is a programming error in 10.0.3 drag’n’drop
Following @CherylC 's procedure on the same databases that she submitted, I was able to recreate the problem where a transferred person was assigned a different set of parents from those he had in the originating database.
FAMILY is the working database of which DB1 is a copy into which a Nancy Farr and her descendants with spouses was drag’n’dropped from DB2. She was merged in that process with her duplicate in DB1. Duplicate Search turns up two Rayburn Alton Rogers: RIN 36880 in FAMILY & DB1 and 43880 newly created in DB1 from 24261 in DB2. DB1’s new 43880 was assigned new parents from DB1 instead of his parents from DB2. He shouldn’t have been assigned any parents because he is only a spouse of a descendant of Nancy Farr.
There is no record in the ChildTable of the pre-dnd DB1 for a ChildID 43880 so this is not a case of a pre-existing phantom record. A closer look at the parents shows the RINs of his parents in the source DB2 (24280 and 24281) have been carried over into a new ChildTable record for 43880 in the target DB1 when there should have been no such record created. Those RINs are for different people in DB1 than in DB2, hence the strange appearance of two females as the parents, of which the mother died as an infant long before their son was born.
I have tested this file and when running the database tools the Integrity check failed. I do not know where the corruption is but it obviously has issues. I do question SQLite tools having been run in the past. Though she said not this one.
Yes, as I’ve reported before, a database that has been developed on MacOS will fail the RM and SQLite Integrity Tests on Windows and vice-versa. Running Rebuild Indexes results in the RM Integrity Test OK’ing. I ran the Rebuild Indexes and cleared the Integrity Test on both databases before the drag’n’drop. The reason that happens is that RM Inc’s proprietary RMNOCASE collation sequence for matching and sorting name-type columns is not identical between the two OSes. Others better-versed than I have pointed to underlying differences in the two OSes as the root cause. That is not the issue here.
The drag’n’drop procedure itself is at fault for creating an erroneous child-parent linkage for a person when no such record should have been created. Transferring descendants with spouses should not create a parent-couple for the descendant’s spouse when the spouse is not a descendant. Alternatively, if it is intended that a descendant’s spouse’s parents should be transferred (I think there have been such requests), then the procedure is faulty because it fails to do so correctly.
BTW, opening a RM database with a SQLite tool that does not write to the database has no effect on the data or the database structure. Read-only queries can be executed without risk. OTOH, write queries do carry risk, which is why we always advise people to follow risk-avoidance and recovery practices.
3 Likes
Some further stats from @CherylC 's drag’n’drop problem. Of the 1387 individuals transferred, a total of 19 spouses of descendants were transferred along with new, erroneous child-parent records in which their parent-family contains the RINs for the couple from the source database which get wrongly named by the name records in the target database.
Moreover, these erroneous parents may get a Marriage event added to their profiles which comes from the real parents in the source database. Here’s an example:
Minnie Phillips is the non-descendant spouse of a descendant (red color). The result of the transfer shows her erroneous parents having been born after she was, and they received a marriage event from the source database which occurred before they were born.
Here’s Minnie’s parents from the source database. Note that the Marriage event added to erroneous mother Wayne Lee MacMillan-24229 came from her real mother Florence Rich-24229 (same RIN).
I have not looked into whether there may be other corruption of data in drag’n’drop. It has taken some doing to wrap my head around this case.
@CherylC AND @TomH
– how are you selecting the people for your drag and drop?
I have had this happen in several different ways-- one is by using a saved search and the other two ways, I mentioned in a thread on here back in August…
I mentioned 4 ways to move groups and 2 of them created problems…
Seems to me the problem is how you create the group to move
@rzamor1 I have NEVER USED SQLite tools on my database…
I’m declaring increasing puzzlement over what is happening in the RM10 drag’n’drop of this particular set of people (descendants and their spouses). When I do so from the copy of the original database to an empty database, I can easily identify from a SQLite query the instances where erroneous parentage is created. If I export the same people to GEDCOM, import to a new database preserving record numbers and then drag’n’drop to a new db, I cannot detect erroneous parentage using the same query. It would suggest that the export-import omits or ignores something in the source database that is included in or triggers a fault in the RM10 drag’n’drop. What that may be could be a needle in a haystack.
I was copying (drag and drop) married couples and their descendants + spouses only - no ancestors, as those were already in the target database. I went back and read all of your original comments and it sounds like you ran into the same problems I did. Are you using the Mac or Windows version of RM10?