Looking at the Enhanced Properties List, Fact Types section, I see no selection for removing duplicate facts in individual records. Per RootsMagic Support the only way to remove duplicate facts in records is to read, compare and remove the duplicates manually. This is absurd and duplicate facts bloat the database. They could easily be removed by doing a line item comparison within the records. This is basic database maintenance and should be implemented ASAP.
I can think of several reasons I wouldn’t want to remove duplicate facts. My primary one is newspaper articles. I can have multiple articles on the same day from different newspapers. Each of them gets their own fact.
The cause of why you have so many duplicate facts is more the issue. The most common reason I see duplicate facts is when merging takes place. If you don’t clean up the place list before merging you will get duplicate facts even if the place names are identical, but are actually separate places in the place list. Clean and merge the place list before you start merging people. Same goes for addresses, repositories, sources and citations.
I would argue for ways to better identify and report them – but the design to allow “duplicates” is correct in this case. The process would to fix them should still be a manual process.
You could suggest an enhancement request to report them. There are two good outside tools to identify them (via GEDCOM).
Family Tree Analyzer (aka FTA)
https://ftanalyzer.com/ (also avail from Microsoft store for free)
GEDMINER
If you have multiple newspaper articles containing duplicate facts then your data is not being parsed correctly. You never want to have ambiguity in a database like that.
If you are familiar with most database managers you can selectively control what items in a database can be validated.
That would be ideal:
Like date of birth and first name and last name and etc…
I have thousands of records in my database, from Ancestry, Family Search, et al and if those are merged you can not avoid getting duplicate facts.
I am not going to waste my life trying to manually resolve an issue that can easily be handled by proper database management.
My first thought is that maybe you should sit down and design your ideal database then write the program around it. Then and only then you would have what you want. What RM does in regards to duplicate facts is pretty much inline with most all of the other major genealogy software out there. Your brilliant suggestion is going to break more things than it fixes based on how the average person uses the software. Renee gives an example of multiple Newspaper items. I have have something similar with my Clips and Obituary facts. Both can exist multiple times for any individual based on what items I find in the newspapers. It is not uncommon for me to have two or three obituaries for a person, all the same date, just different newspapers. Things such as Place or sometimes the same. My Clips fact is similar. Sometimes I have a relative that appeared multiple times on one page of a newspaper on the same day and in the same place.
Genealogy software should require manual handling so as to not inadvertently delete items that may appear duplicate but in reality are not.
I can imagine a duplicate facts detection and removal that goes much further than comparing just Fact Type and Date, as in your example. Extend it to Description, Place, Place Detail, Note, Media, Citations, WebTags (remember the upset caused by Merge All Duplicate Citations that failed to take into account Media and Webtag). If a Fact for an individual or a couple matches another Fact for the same object across all these parameters, it is truly a redundant duplicate and can be deleted without any loss of information and succeeds in removing clutter.
It is not very difficult to develop a perfectly safe bulk delete function for duplicate facts and to add to the Tools.
1 Like
A merge tool could work similar to the way citations/ sources
my concern would be that (too) many users would not understand the consequences of their actions. Seaborn might be an advanced users but that would not be true for majority of users.
I agree for the need to better identify duplicate facts – I check every couple months with FTA and/or GEDMINER most cases.
Genealogical database are not like a standard relationtional db.
There is “fuzziness” and that is often needed. Also to be able to source and cite might be anoter reason.
In a standard relational database, duplication is a sin—it wastes storage, invites update anomalies, and violates normalization rules (like 3NF). However, in genealogy and the GEDCOM standard, duplicate facts (multiple entries with the same GEDCOM tag, such as multiple BIRT, RESI, or OCCU events for a single individual) are not only necessary; they are essential for rigorous historical analysis.
Here is why duplicating facts by GEDCOM tag is required to handle real-world historical data:
1. Competing Evidence and Conflicting Assertions
Genealogy is an investigative science built on indirect, contradictory, and secondary evidence.
-
The Problem: If an 1850 Census says an ancestor was born in 1810, an 1860 Census says 1812, and their tombstone says 1808, you cannot overwrite a single
BIRT(Birth) field without destroying historical data. -
The Solution: Storing multiple
BIRTorEVENfacts allows the database to hold all conflicting claims side-by-side. Each duplicate fact acts as a distinct hypothesis, carrying its own independent source citation, reliability assessment, and qualitative evaluation (e.g., Primary evidence vs. Informant bias).
2. Temporal and Jurisdictional Evolution (Life Stages)
Many GEDCOM tags represent attributes that naturally change over time.
-
The Problem: A person has multiple residences (
RESI), occupations (OCCU), or physical descriptions (DSCR). If you normalize a database to only allow one occupation per person, updating a person’s later-life profession obliterates their early-life career. -
The Solution: Duplicating the tag allows you to map a person’s changing lifecycle. You can have three
OCCUtags: one for Farmer (1850), one for Blacksmith (1865), and one for Merchant (1880), each anchored to specific dates and place contexts.
3. Granular Source Provenance and Citation Mapping
In professional genealogical data models (like RootsMagic or GEDCOM 5.5.1/7.0 specifications), a source citation is tied directly to the fact assertion, not just the person.
-
The Problem: If you merge a birth date from a baptism record and a civil birth registration into a single compressed field, you lose the ability to cite them independently.
-
The Solution: Maintaining duplicate facts separates the evidentiary threads. Fact A (
BIRT) is tied via a citation link to a church register, while Fact B (BIRT) is tied to a delayed state birth certificate. This granular separation is vital when performing data audits, running anomaly checks via tools like GEDminer, or tracking down citation errors.
4. Merging Disparate Datasets (GEDCOM Imports)
When merging family trees from different researchers or importing large GEDCOM files, duplicate facts naturally occur.
-
Instead of letting an automated script blindly overwrite existing data (which causes irreversible data loss), a well-designed genealogy tool imports incoming duplicate tags as un-merged alternate facts.
-
This gives the researcher the architectural space to manually review, compare, and decide whether to keep both instances as competing viewpoints or merge them using a sound correlation process.
By embracing duplicated fact tags, the database shifts from storing objective constants to recording a chronicle of historical claims, allowing researchers to weigh evidence and build arguments rather than forcing messy history into clean, rigid boxes.
(CREDIT AI - GEMINI)
1 Like
if you are familiar with Database Design and sql (sqlite) then you have option to work directly with the database on your own (though that is not supported by RM) you can do so on your own as many of us do.
I try to do most every within RM but there are things I use customer SQLITE scripts for still - but with each version – I need to do that fewer especially with the advanced search
You really should credit where that nicely formatted commentary came from.
1 Like
well since it AI and I prompted it – it only deserves partial credit 
but fair point