Citation merge change in 10.0.4

Continuing the discussion from New RootsMagic Update (10.0.4):

Is there a little more information about this change/improvement?

I was under the impression that there was a problem where the merge did not take account of differences in attached media or web tags, resulting in unwelcome merges if that was the only area of difference. Does this change resolve that problem?

1 Like

We cannot take webtags and media into consideration when merging all duplicate citations. It is typically the sources that come from Ancestry that have the greatest number of source citations with no citation name and blank citation details, yet have media or webtags attached. It is undesirable to merge those because you could potentially have citations with thousands of webtags attached. This is why we now prevent citations with blank names and fields to no longer be considered matches. If you manually enter a blank citation it will add semi-colons to the citation name. Semi-colons only are also considered blank and will not merge.

This change will allow the user to review the remaining unmerged citations and assign them unique citation names to control merging or manually merge them if desired.

I had wondered the same thing: is 10.0.4.0 addressing the problem of ancestry citations merging when they shouldn’t merge? But I didn’t want to raise the question until the problems with drag and drop had settled down.

But now that the question has been asked and answered, I have to say that I don’t understand the answer. It’s not so much that I don’t agree with the answer. It really is that I don’t understand the answer.

In the first place , we have “We cannot take webtags and media into consideration when merging all duplicate citations.” But why not? All the code involved with Merge All Duplicate Citations is on the RM side of the house and none of it is on the Ancestry side of the house. But then we have “It is undesirable to merge those (with no citation name and blank citation details ) because you could potentially have citations with thousands of webtags attached.” That is correct and that is what users have been contending all along So what is going on? We can’t solve the problem but we did solve the problem?

So my first read is that the fix solves the problem but it solves it with a very different logic than was being suggested by the users. As a practical matter, not merging citations with no citation names and blank citation details has the effect of not merging citations that differ only in their webtags.

So far, so good. But what about citations from ancestry which have no citation names and blank citation detiails and which have the same webtags? Should they not be merged?

2 Likes

I cannot speak to the internal workings of programming and why media and citations cannot be considered. I only know they cannot. If you add a new citation you will see the media and webtags cannot be added until after you save the citation. All the fields that are on that add citation screen are taken into consideration when comparing duplicates. Additions are not. The best we can do is find the most common cause of the problem and that came down to blank citation names with all blank citation fields as the most likely to have media and webtag that should not be merged attached to them. This was the best way for us to address this.

This feature bit me a couple of years ago and I am still repairing the damage. Ancestry was nor involved, just a newbie user of RM.

It is feasible to differentiate citations among those that are identical in every respect except for the media or webtag. I’ve done it using SQLite. All the necessary data is present in the database. I cannot understand why you might have been told that it is impossible. It has nothing to do with the sequence with which media or webtags get added to a citation. There is no such sequence needed nor screens to consider for the Merge all duplicate citations function to execute.