I have two NameTable records for a single PersonID in which the records are nearly identical. (the mod date and isprimary are different. However the forward-facing information “Given” name is different: “Jesse” vs. “Jesse V” I’m tempted to merge these two records, why shouldn’t I?
I use RM7 so my suggestion would be more simple than with RM10 What I do before merging, I edit one or the other of the duplicates so they are alike except for the record number. Then I don’t have to spend much time adjusting details after the merge.
RootsMagic has no means of merging a primary name and an alternate name. “Jessie V” gives a little more info than does “Jessie” and is already the primary name. I see no benefit by keeping the alternate name so I would just delete it.
As to Jesse vs. Jesse V., I would keep one but not the other. But I wouldn’t automatically keep the Jesse V. just because it’s more information. I would only keep it if I had evidence for the middle initial. Well, I might keep Jesse V. as an Alternate Name without evidence, and then make a note that I didn’t have any evidence and that needed to try to find it.
All respondents other than myself have erroneously thought that these are two different people in the database when the OP states the names belong to the same person. I don’t understand why it was necessary to post data from the two records in NameTable but they clearly show that the OwnerID for both is RIN 9647.
I agree with your point about making the one with the stronger evidence the primary name.
Yes, these are two Name records for the same Person. I am tempted to merge the two name records. Maybe RM doesn’t have a way to do this conveniently, but is possible outside of RM, e.g. via sqlite3.
I decided to ask seasoned users their opinion on this, and thank you for your responses.
When I asked Gemini (Google’s AI assistant) this same question, its response stated that was a “best practice” to keep both NameTable entries.
I understand your human intuition to consolidate information, and you’ve hit on a common thought process in genealogy!
However, in the context of RootsMagic’s database structure and genealogical best practices, these two NameTable entries are already “merged” at the individual level. They both belong to the same person (OwnerID 9647).
Here’s how RootsMagic handles this, and why the current setup is generally preferred:
Alternate Names, Not Duplicates: These aren’t duplicate people that need merging. They are two variations of the name for a single person. RootsMagic explicitly allows for a person to have multiple name records (e.g., birth name, married name, various spellings, names found with/without middle initials).
IsPrimary Field’s Purpose: The IsPrimary field does exactly what you’re intending. NameID 10271 (Jessie V Kelley) is already set as IsPrimary: 1, meaning RootsMagic will use “Jessie V Kelley” as the main name for display, reports, and indexing for that individual. NameID 10272 (Jessie Kelley) is IsPrimary: 0, marking it as an alternate name.
Source Linking: The key benefit of having both entries is for source documentation. If you find a census record where the name is clearly just “Jessie Kelley,” you can link that source directly to the NameID 10272 entry. If you then find a birth certificate for “Jessie V Kelley,” you link that source to NameID 10271. This level of detail in source citation is highly valued in Evidence Explained style genealogy, as it accurately reflects what the source says.
Your Assumption is Validated: Your assumption that “Jessie Kelley” was found without the middle initial is exactly why you’d keep both. It’s a true representation of the evidence.
In summary:
You do not need to “merge” these in the sense of combining two separate NameID records into one new NameID. They are already linked to the same person.
The system is already configured as you desire: “Jessie V Kelley” is the primary name (IsPrimary: 1).
It’s best practice to keep both name entries. This allows you to link specific sources to the precise name variation found on that source, enhancing the rigor and transparency of your research.
RootsMagic’s structure is designed to accommodate these exact scenarios, allowing for a comprehensive and accurately sourced family tree.
Hi Tom, The purpose of showing the full details of both records was to illustrate that the two records were nearly identical and merging wouldn’t result in pertinent data loss.
I originally interpreted the question as being about merging two people rather than as being about merging two rows of the same database table. But if it’s really about merging two rows of the same database table, the merge would have to decide for each column which data to keep and which to not to keep. The “not kept” row would then have to be deleted.
It seems to me that you can do that manually in RM just as easily or more easily than you could with an SQLite script. More importantly, I don’t know how a general “merge two rows of the NameTable” could possible know which data to keep and which not to keep. Also, if either row was linked to by things like media or citations, then your script would have to attend to adjusting those links as well. This is one for the “keep it simple” principle. Just do it yourself from the RM user interface.
The one thing you could do easily in SQLite would be to delete all the Alternate Names and keep all the Primary Names. And even then, you would have to delete all the media links and citation links to the Alternate Names. But I don’t think that’s what you have in mind.
I’m surprised at how much Gemini ‘knows’ about RM. And about Evidence Explained. I see people discussing all kinds of things they are doing with various AI platforms in the Genealogy and Artificial Intelligence group on Facebook. I wonder if the RootsMagician is looking at how to capitalize on AI for RM. If it’s not already the ‘big thing’, it soon will be.
The question is more of a philosophical one of whether to merge or not, versus the mechanics of doing so. Just trying to see what others would, or are, doing in the maintanance of their databases.
So far, based upon the small sampling: Most users would merge these two records in the NameTable.
However, I feel that Gemini does make a good point. In contrast OpenAI’s ChatGPT doesn’t see a practical problem.
Yes, these two RootsMagic NameTable entries for NameID 10271 and NameID 10272can be safely merged.
Justification:
Same OwnerID: Both records belong to the same person (OwnerID = 9647).
Surname & SurnameMP match: "Kelley" and "kelley" match exactly.
Given & GivenMP difference is minor: "Jessie V" vs "Jessie" — the second name likely just omits the middle initial.
Same BirthYear and DeathYear: 1880–1918 for both.
All other fields are either blank or identical, including Prefix, Suffix, Nickname, Language, and Flags (IsPrimary, IsPrivate, etc.).
Only one marked as primary (IsPrimary = 1 on NameID 10271).
Merge Recommendation:
Keep NameID 10271 (more complete, includes middle initial V).
Remove NameID 10272.
Ensure that any foreign keys or references (e.g., in PersonTable, CitationLinkTable, etc.) that point to 10272 are updated to 10271.
Update UTCModDate on the surviving record after merge.
Would you like a script that safely performs this merge and updates all references?
Both AI engines were provided with the database schema, but seemed to “know” quite a bit about RootsMagic itself. I did prompt ChatGPT with a reference to “Evidence Explained” at one point in time and it was familiar with the work. However, I had very little legacy with Gemini and the reference to EE came out the blue.
Why is your approach outside the program? The change you are suggesting is accomplished in short order by editing the Given name entry block to whichever of those two desired, then deleting the Alternate Name fact.
That’s a good question. This is due to preference and existing skill set that I work from a command line interface versus a GUI. It’s also an interesting programming problem to solve.
My database is what some might think is large, e.g. 15k+ persons, and contains the results of some of my sloppy habits. My goal is clean it up and “normalize” it. Clicking my way through a GUI isn’t something that I would enjoy, or care to do.
I just finished with the PlaceTable and was able to reduce the number of PlaceTable records from about 6000 to about 4000: merging duplicates, standardizing place names, moving or removing erroneous entries, etc. I’ve now started on the NameTable, and that’s what precipitated the original question.
My endeavour lets me combine two of my past times.
I empathize with that point of view. GUI interfaces are often pretty clicky. I thought the RM7 user interface was way too clicky. And even though a stated goal for RM8 was to make it less clicky, in practice I find RM8/9/10 to be much more clicky than was RM7. I prefer user interfaces that look and feel more like a traditional spreadsheet, and where you can type directly into the cells. For example, I frequently wish I could type directly into the cells in the left panel of RM’s Edit Person screen rather than needing to highlight a row in the left and then typing the data into the right panel. And the sliding panels make the clickiness much worse for me when I need to see the media and citations (and the media for the citations) associated with facts in the left hand panel.
But here is the counter argument. You can actually look at RM’s database with something like Microsoft Excel if you wish to do so, using ODBC. But for me, the problem with that approach or of a command line approach with SQLite is all the table joins that are required by almost any relational database. A simple example would be your case of merging two rows of RM’s NameTable. What if both rows are joined by the CitationLinkTable and the MediaLinkTable? That would be a typical situation for me because I try to have both a media file and a citation for every fact. I can’t see how to deal with the adjusting the joins very well from either a spreadsheet view or a command line interface.
I do use SQLite very heavily with RM. But mostly it’s for reporting that’s difficult or impossible to achieve from the RM user interface. And on the rare occasions when I actually do SQLite updates to my RM database, I’m super careful that the code is well tested and that it handles all the joins correctly. Even though I dislike the clickiness, I dislike a corrupted database even more.
Justification:
Merge Recommendation: