Requires the REGEXP extension which is not included in all SQLite managers SQLiteSpy does support it. This feature is of uncertain value.Ī temporary table xRefnBak is created by the script and is deleted when the SQLite manager closes the database. The script also preserves and pushes to the front existing FSID Ref# facts for a person not currently matched in the database to Family Search, i.e., the FSID has been somehow lost or the fact was manually added. This script shuffles existing Ref# facts to follow the FSID Ref# facts it creates by copying the former out to a temp fable xRefnBak, deleting the originals from the EventTable and then appending them after the FSID Ref# facts are created. This enables the Duplicate Search Merge (DSM) option “Find people with the same reference numbers (and ignore everything else)” to pair up people with the same FSID Ref#. Sample of database after script has run to copy the FamilySearch ID into the first Ref# fact for each person for those persons having been matched to FamilySearch.Ĭreates a Ref# fact containing the FamilySearch ID for each person in the database matched to a person on FamilySearch Family Tree in the format “fsid: XXXX-XXX”. Thus it requires this FSID Ref# fact to be the lowest record number of all the Ref# facts for a person in the EventTable.Įnter a SQLite script that addresses these issues enabling DSM to pair up matching FSID Ref# facts. Duplicate Search Merge compares only the first Ref# fact for a person to the first Ref# fact for each other person. Moreover, it is complicated if the people have pre-existing Ref# facts for other purposes that must be preserved. Getting the FSID into a Ref# fact is a laborious task if there are more than a few people to do. This should also be useful when people matched to FamilySearch get duplicated in a database through other avenues such as overlapping downloads from FamilySearch into the same database. “Find people with the same FamilySearch ID (ignore all other information)”Ībsent that third option, the user figured that if she could get the FSID into a Reference Number (Ref#) fact for each person, the databases could be combined and DSM with option 2 would reliably pair up the duplicate people.Wouldn’t it be nice if there was another option: “Find people with the same reference numbers (ignore all other information)”.“Find people with the same Ancestral File numbers (ignore all other information)”.That seems to be a shortcoming that should be addressed. Unfortunately, Compare Files does not a high match make for duplicate FSIDs. But they have been matched to the same FamilySearch persons and thus have the FamilySearch ID (FSID) in common. Because the duplicated people were created independently, she cannot rely on the RootsMagic File>Compare Files tool to unambiguously pair them based on a common UID (RootsMagic’s hidden Universal Identification) because their UID’s are different. One was her master with people matched to FamilySearch the other was developed independently using FamilySearch. This script responds to a user’s problem posted on FaceBook: she had two databases with overlapping people in them.