I'm new here, so please excuse me if this has already been discussed. When you have duplicate records and one has only the wife's name (the record to be "kept") and the other has husband and wife's names (the record to be "deleted") and you schedule a merge, why is the husband's name NOT merged into the "kept" record? The logical conclusion for a merge of duplicate records is that all "unique" information will end up in the "kept" record, yet I am not seeing this happen. Can anyone explain if (a) I'm doing something wrong, or (b) if this is a software glitch that needs to be rectified?
Bonny, Colorado Ballet
The merge process does not itself cross reference the names on the "delete" vs the keep. It just keeps whatever names are on the keep. Probably because there's no good way to know when merging if the name in the "delete" really ought to be name2 on the kept record, or if it's an alternate name for name1. This will probably be a moot point in v11 since there won't be name2s anymore. The short answer is: what you expected to happen with the name2 is not the expected behavior of the merge process.
There's really good documentation on exactly what the merge process does though, what gets moved from one record to the other vs what is automatically left as whatever it was on the "keep". I am forgetting which document it is at the moment...but I know I read it somewhere other than in the sp.
In our local merge procedure we have a section that checks if there are names in the "delete" that are not in the "keep" and not in an alias of the "keep" and if that's the case it adds an alias to the keep with the "delete"d name. This saves us the step of cleanup on dups where, for example, the keep says "William" but the delete says "Bill". So the patron remains searchable by either name. If the two names are clearly different people, in theory we'd have the person scheduling the merge add the second name as name2 on the keep prior to scheduling the merge. But if someone forgot, we'd still have it at least as an alias.