Merging when duplicate child attached to only one parent

vNatale

When merging a duplicate child who has been connected to only one parent, the resulting conclusion shows the child as a child of the original couple, but then again as a child of only the one parent. There is no option to show the child only with the couple and not the one parent. Example: new profile for Elizabeth Wickliffe PMGL-29B was created (2025) and attached to only the father, Robert Wickliffe. The existing profile for Elizabeth Wickliffe M83D-2S6 (created in 2012) was attached to both mother and father (the same Robert Wickliffe). When the merge was completed, the results are showing Elizabeth as a child of the couple (which was what the original profile had) AND then she lingers again as a child of just the father at the bottom under the list of all the children of the couple. Now, the merger must examine the results, scroll down to the bottom of the screen to see that this new attachment to just the father has happened and go through a second clean-up to unattached the child from just the father. So many extra unnecessary steps, and most people don't realize that it happened and don't do those extra steps to finish the process. The current merge process allows you to not move over the one parent as a duplicate attachment.

Gordon Collett

That is one of the things that I like about the new merge process. It decrease the risk that important information will be lost. I have found that it is always best to pull over all parents and take those extra steps of adding a temporary mother to the father/child relationship that does not have one then merging the the two mothers. It just keeps things cleaner to merge relationships rather than delete them.

As an example of the problems that trying to fix relationships during a merge came up recently. I was reviewing a record in the Improve Place Names activity and was given a record with only the woman's name and a one word birth place. I had to go look at the profile to see what was going on. It was evident after going through her change log that this was a series of twigs in which someone had merged multiple copies of her husband to collect all their children into one family and during the merge process just lopped her off. So now there are about six duplicates of the woman with minimal information floating as isolated profiles. Just merging duplicates then fixing relationships would have prevented this.

vNatale

Gordon – I understand your concern about some family members getting “lopped off” during a merge. However, the example that I am providing herein is different from that. This example is a duplicate child who was connect to a father but not the mother. The original profile for this child is connected to the SAME father and her mother. There were no extra parents involved. In the merging process, the father is connected TWICE to this child, once with the intact family structure with his wife (as was originally shown with the original profile for the child), and then again, singly listed below the intact family structure as a single father of one lone child (because that’s the sole connection shown for the duplicate child). That happened because the new merge process does not allow the merger to uncheck the SAME father from being connected to this child a second time. Most people even miss that it happens that way, because after you perform the merge, you must scroll down past all the children in the intact family structure to see the dangling repeat of the child connected to just the father a SECOND time. I see this happen frequently. The contributor who created the duplicate child only knew the father’s name and made the connection to him. That does not mean there was a different mother; it just means the contributor had not done further research to discover her name. It would just be a lot cleaner if the merging process could recognize that the parent for both profiles being merged was the SAME parent and did not result in a second connection to the same child.

Gordon Collett

There are thousands of father/child; father/mother; father/mother/child records from the IGI in which the father/child record has background data that is lost unless the relationships are properly merged. That is my concern. You can't see that data unless you merge add the mother to the father/child record then merge all the individuals together properly.

vNatale

There is no merging of the parents to be done in this case. Both children are attached to the same father. Merges simply add an unnecessary DUPLICATE connection that must be deleted after the merge. And most contributors don't realize that it happened because they don't scroll all the way down the screen after the merge to see the duplicate dangling relationship.

Gordon Collett

It's just my personal preference based on observation in a select set of circumstances that there is lower risk of losing data if when a merge will create this situation (with the example created in Beta):

if one preserves all the relationships during the merge and afterwards adds a wife:

then merges the two wives. Yes, its a few more steps but I feel preserving background data is more important that speed.

If someone does a merge and doesn't catch the extra parental relationship and gets that merged, someone else will eventually.

vNatale

This example still illustrates when there are two wives to merge. My example included NO second wife. I still contend that the process would be more exacting and smoother if, in the scenario of no second wife, that the merging did not automatically attach the child a second time to just the father. My concern is not so much just "speed" but in consideration of the contributors who work so diligently every day to try to keep our tree in a relatively reasonable state. When so much work is placed on these volunteers to clean up after the excessive duplicates that are attached daily, eventually people get worn out from the task and give up. We don't want that. We need these volunteers. I have seen profiles that had 50 or more children attached because no one tried to process and clean up the duplicates. Any automated processes from the system that can assist in this work would be greatly appreciated.

Gordon Collett

Note that in the first illustration in my post, there is no wife. I had to add the temporary second wife "e" to then merge relationships.

I do certainly agree that getting all the duplicates merged is still a big job. But I would rather have someone only halfway merge a family and overlook a bunch of duplicates than to merge them incorrectly and lose information in the process. It's easier to complete a merge than to track down problems that occurred during a merge.

jerroleensorensen1

I agree with vNatale. It is extremely annoying that you cannot choose whether to include certain information. It causes extra work and for people who are not like you and me :), it won't get done and will cause more problems.

Mary Anna Ebert

We cannot automatically merge cases like this because situations happen where a child could only know one parent, and then that parent remarries, and they get an adoptive parent.

While we introduce a second step to go clean up situations where you know it's just an extra relationship showing, it does make understanding what happened in a merge much simpler.