Thanks for moving children over automatically in new merge process!

LegacyUser

Stephanie Spencer Booth said: I just had to find and add five children that were left off in a merge done last year. I've had to do this so many times. I can't tell you how glad I am that you've changed the merge process to automatically move children and spouses over to the surviving record unless they are manually removed. So many people merge who don't have a clue what they are doing. This really helps keep families intact when a novice is trying the merge process when they shouldn't be doing it without help.

LegacyUser

Stephanie Spencer Booth said: I forgot to add thank you for making the parents move over automatically also. I just discovered the man who lost five children in a merge, also lost his parents in the same merge. I'm not even related to him now. Keep up the improvements!

LegacyUser

Jeff Wiseman said: Yes, I'm really happy that ALL relationships are maintained through a merge! Even if they wind up being duplicates in the final family. I was discovering too many that people were "cutting free" those extra names that they didn't think were needed.

LegacyUser

Carol Anne Lethaby said: The first couple of times I had to really pay attention to catch all the new features...but now...merging is SO MUCH FASTER! It's also easier to check for duplicate ID's on the right so I can UNDO the duplicates....so I don't get those one parent combos on the Person page. Thank-you!!!!!

LegacyUser

gasmodels said: just be careful if the parent ID's are not the same. Removing a single parent because the name is the same but the ID is different can cause ordinance issues.

LegacyUser

Jeff Wiseman said: Yes, and when you get duplicate children being combined in the same family due to parents being merged, you DON'T want to undo those prior to the merge. Bring them all over and you'll discover that the wind up setting next to each other in the family display. That way they will be a cinch to spot and later merge.

LegacyUser

Paul said: I remain rather unhappy with the UNDO facility, though I admit I have used it on the odd occasion (but not in relation to children). What's the point of adopting the previously much-requested feature of children coming across automatically in the process when it's so easy to move them straight back?

LegacyUser

Carol Anne Lethaby said: That's why we look for duplicate ID's...not just names.

LegacyUser

Jeff Wiseman said: Sorry, missed that.

Yes, when the IDs are the same, having the ability to choose "which one" you want is useful as sometimes the parent-child relationship types that have been defined on one are missing on the other. By choosing between the two identical IDs that have different relationship types during the merge can hasten post merge cleanup a bit.

LegacyUser

Jeff Wiseman said: Agreed. If the two PIDs being merged are supposedly "the same person", then any relationships that either of them have should be accumulative in the surviving PID as well. This is just like sources--they should accumulated during the merge.

Cutting related PIDs free to float in the aether of the database during a merge operation is a bad practice because they will inevitably be forgotten and lost.

LegacyUser

Carol Anne Lethaby said: "Like"!

LegacyUser

Stephanie Spencer Booth said: Jeff, I agree. I can't stand when children or spouses get lost in a merge because someone wasn't paying attention or not aware that there were more children or spouses.

I experienced a glitch twice on Sunday when two merges removed the children from the person being merged even though they had been moved over. I sent a message to support, but because I had already manually added the children back by the time they looked at it, they didn't understand the problem. So far, it hasn't happened again. I'm glad I know how to look at the record history to find the children that have been removed.

I really like having the dates the records were created on the merge page. Hopefully users will get the subtle hint to keep the old record with it's history, not the new duplicate they created 5 minutes ago.

LegacyUser

Jeff Wiseman said: Stephanie,

I really hope that FS enforces the concept that I mentioned--i.e., if you have decided that two different PIDs are the same person, all data during a merge should be accumulative--keep it all. The only time that there is an issue that needs a manual "tweak" is when both PIDs contain a value for the same vital. Then you need to discern which is better, and if the vitals need to be merged, either prepare them before the merge, or clean up the survivor after the merge.

Changing anything else during the merge (right or wrong) will only be buried in the change history (or maybe not even recorded at all!). Do the prep and cleanup OUTSIDE of the merge operation so that the change histories can be more easily used to track down mistakes.

The merge function has been revamped to a large degree and I suspect that there are likely more problems with it as several have already been reported. If you see something like that again, report it in a new topic here on the feedback forum--that's one of the main reasons it's here. I typically don't use customer support because all of my questions are dealing with issues that customer support typically don't have any familiarity with and bugs in the system are just one of those issues.