Records say the darnedest things.
People have noticed that duplicates exist for some records on FamilySearch.org. There are good reasons. As the Church of Jesus Christ of Latter-day Saints upgraded their computer systems, information was migrated from one to another. In some instances, information was migrated to multiple places for multiple reasons. Records might be shuttled off to the online International Genealogical Index database. Independently, they might be sent to the British Vital Records Index CD-ROMS. Judging from what FamilySearch has published online, it appears that sometimes information was lost during migrations. And sometimes it wasn’t always the same information. FamilySearch appears to have done the conservative thing and published duplicate records, just in case.
Here’s an example. There is a record of the marriage of Nicholas Chatterton to Joan Aault on FHL microfilm 496,705. It was indexed in batch M05442-2. It has been published twice.
It made its way to FamilySearch.org via “England-ODM,” as indicated by the “System Origin.” I think that is the equivalent of “England IGI.” (See the FamilySearch Help Center for more information about system origin.) Notice that the event date (why doesn’t FamilySearch call it a marriage date like Ancestry does? Why confuse people?) is 1 August 1568. Notice that the event place is Longford, Derbyshire, England. We’ll learn later that that is the wrong location. This first record has the complete date and the wrong location.
Another copy is https://familysearch.org/ark:/61903/1:1:NJHJ-152.
It made its way to FamilySearch.org via “England-VR,” which I think means the British Vital Records CD-ROMs. Notice that the event date is 1568. FamilySearch has lost the month and day, 1 August. Notice that the event place is Etwall, not Longford, in Derbyshire. This second record has an incomplete date, but the correct location.
If FamilySearch removes one of these duplicates—whichever one—they lose information not present in the other. Now do you see why there are duplicate records on FamilySearch.org? I know people who, when finding duplicate hints, accept one and mark the other as not-a-match. Don’t do that. In the first place, that damages the hinting system. In the second, you may be throwing away information.
By now you’re wondering how I knew which location was the correct one. That is an excellent question. First, I looked up the film number in the catalog, expecting it to list one of the two parishes. It listed both. That left the batch number as my only hope. Here you’ll have to go old school: look up the batch number in the PVRL (Parish and Vital Records Listing) on microfiche. I’m disappointed that FamilySearch hasn’t published the PVRL online. You’ll have to find a family history center that has kept their PVRL microfiche—and kept a fiche reader. Go to the center and look up the batch number to check the name of the parish, hoping the batch wasn’t extracted after the fiche was published. When you complete this exercise, you find that Etwall is correct.
By now you’re also wondering how prevalent blatant place errors are in FamilySearch’s records. There is something you can do to get a feeling as to the quality of a collection. From the collection’s main page, select “Learn More.” That takes you to a wiki article about the collection. Scroll down looking for the section titled “Known Issues with This Collection.” Click the icon to get to the wiki article about the errors in the collection. The “England Marriages, 1538-1973” collection has four screens of errors. One line addresses our error:
Film 0496705, Batch M05442-2: The correct event place as Longford, Derbyshire, not Etwall, Derbyshire.
That’s opposite of my conclusion. Going back to the PVRL, I looked up Etwall and Longford. The batch number for Etwall is M05442-2. The batch number for Longford is M05549-2. Either the PVRL is wrong or the wiki is wrong. My guess is that the wiki has it backwards. But who can tell?
There are a couple of things to learn here. Don’t assume that a computer file is copied exactly when migrated from place to another. In this example, database programmers introduced the errors, not non-English speaking indexers. And never, never trust a derivative record. Always, always find and look at the original or a trustworthy image of it.
Yes, records say the darnedest things.