What does this mean? I understand blank names, but is this trying to say that if ANY field is blank, the auto merge will not work?
I agree that the workaround is not difficult. The difficult part is knowing that this behavior exists in the first place.
Looking at the list of citations, the user sees several that appear to be identical. A reasonable person can hardly be blamed for assuming that selecting a single item from the list would only cause that one selected item to be deleted. There is no visible indication that these items are linked and that selecting one is the same as selecting them all.
It’s a bit of a shock when they suddenly ALL disappear, even though only one was selected.
I’m not sure I understand what exactly was being fixed with this change but so be it.
However, I do not see the harm in giving users an option to explicitly allow merges of citations with blank name fields. The default behavior can remain the same, but in a situation where the user wants these citations merged, they should be allowed to do so.
Exactly what was being fixed was that dozens or perhaps hundreds of unequal citations were being merged. Such citations had blank citation names and were unequal in ways that were not tested by the Merge All Equal Citations tool.
Such citations arose primarily due to downloads of citations from Ancestry via TreeShare. Not all citations downloaded from Ancestry via TreeShare have this problem. In fact, most citations downloaded from Ancestry via TreeShare do not have this problem. But some such citations do. When they exist, such citations come from collections in Ancestry that are “incompletely indexed”. That’s my term for it, and it may not be the best term to describe what’s going on. But for those collections, any citations downloaded from Ancestry will have this problem.
1 Like
@billbremer To give you a little background as to why this was changed-- before the change, users were using merge duplicates on what they thought were EXACT duplicates BUT the ones with the blank citation names were different in that they had different media and/ or webtags attached to them-- so for example one person said that after they have used merged duplicates they ended up with 190 different images/ media attached to one census citation ( such as 1921 U K census)— taking in to consideration all the citations that were merged for census etc, he ended up with thousands of citations that needed to be fixed manually – he couldn’t restore a back up because he didn’t catch it right away— and there were a lot of others who said they had the same problem…
If you don’t want to use your work around of exporting the database by gedcom and import it back in, then you could add something to the citation name fields-- my understand is that you have to have something in PAGE NUMBER ( assuming you are talking abt free form citations) as the citation name is only for your purpose…
That said if the citation name is blank, you could do an advanced search to find them by using any fact and citation name is blank – once you run it, you can do a saved search, make a group and/ or color them–haven’t figured out yet if you can search for info on page number…
2 Likes
Leaving any field blank doesn’t cause an issue. It’s when ALL the citation fields and name are blank that they will no longer merge by intentional design. Others have explained very well why they shouldn’t be automatically merged.
Somewhat related to this discussion pertaining to using Tree Share to download information from Ancestry, I have found that differences in information is not limited to Citations. Many Family members, Facts, Notes, sources and media downloaded from Ancestry are shown as differences when in substance, or actuality, they are not. Especially things like Detail Places and Notes, etc. Some of these are noted in the Tree Share user manual. But some do match exactly yet for some reason still show as differences causing one to have to look at each item to see if it is really different.
As I result I never download anything from Ancestry into my master tree on RM. I use a separate database so that I can compare data before importing into the master database. I then use the compare database tool to find the differences.
However, this causes a different issue. The file compare tools marks many people as different (yes, the Only show people with differences is checked) with a 99% match (some as low as 93%) yet every field is identical. On the other hand many show up as 0% match with a blank record in one or the other databases even though that person is in both databases, often shown as two different records when in fact they are not actually duplicated in the database. This causes an extraordinary effort in comparing files.
So, is there a problem with the compare files tool? Or is it basically just useless?
The scenario you are raising is really not related to the merge duplicate citations action. It deserves a separate post so that you can provide specific examples of the concerns that you have with the file compare tool.
When the Compare Files tool was first introduced into RM, I made an exact copy of my database and compared the original with the exact copy. It found gazillions of differences. How can this be?
I was expecting a tool sort of like tools I was used to using that would compare text files which were nearly the same but where one of the two files might have had some minor edits. The RM tool didn’t work anything like that. Instead, it worked more like RM’s Duplicate Search tool that can be used to find people who might be duplicate so you can merge them. Or another similar way to look at is that it works more like ranked searches work, where sites such as Ancestry and FamilySearch will respond to a search by giving you a long list of possible matches with some sort of ordering or ranking as to how good the matches are.
So if you have men named John Doe on your database who were born in 1845, 1846, 1851, and 1855, then when you compare two copies of the database to itself, each man in each database has four possible matches in the other copy of the database. I don’t know what all criteria the tool uses. It’s surely more than just name and birth date, but I don’t know how much more.
At least that was my guess of how the tool was working. I have run the same test much more recently with the results being much more reasonable. I don’t know if that means that the tool has been improved or if it means that I have cleaned up my database a great deal. Possibly, it’s a little bit of both. In any case, the tool is not a “diffs” utility for your RM database that finds precise and narrow differences.
Thanks, sounds like I have a lot of work to do. I’ll research some more specifics so I can give examples and post in a new discussion as kevinm suggests.
The issue was media, and it was extremely severe. I was forced to restore an older database, redo a couple months of work, delete through SQL many citations, then delete and reload my 25,000 person (at the time) Ancestry tree. Every census citation had all the census media attached to it so it all had to be redone in order for GEDCOM exports or Acnestry to work correctly. All in all it probably cost me a half of a year. Be careful what you wish for, as the results could be rather unrewarding.
1 Like