I find I have duplicated several fact types (baptism x2, Burial & Buried, 3 different Draft/Draft Registration, Immigration x3 …). Not sure how unless it came during misaligned migration from previous software or related to taking data to and fro with Ancestry TreeShare?
Anyway, the question is how to deduplicate the fact types now the new system inspires one to tidy up the data and the menus make it easier to see and access the faults in one’s data collection.
So far I renamed for instance the duplicate baptism (the one without a sentence constructed) as baptism2 and searched:
(Left Side-Bar Search/Person Search Advanced/baptism2/exists/true/click on person/Go To)
for all profiles using that baptism2. Hence I opened each person and changed that baptism2 Fact type (top right, popup menu) to the original baptism, which has the sentence constructed. There were only a handful. But I fear there might be more for other duplicated fact types.
So the option to right-click merge for Fact Types as with Places would be great please.
I think that some time ago (couple years?) I “merged” fact types by changing all of them to be IDENTICAL, then doing a GEDCOM export. It worked, but was a bunch of work, and I( also worry about the occasional loss of data in a GEDCOM trip…
I have merged fact types with SQLite. If you are able to use SQLIte, it’s a very easy thing to do as compared to many of the other things you might wish to change with SQLite. But it obviously requires SQLite programming skills and is therefore inaccessible to most users.
SQLite queries that are only reports are 100% safe. SQLite queries that change things are not 100% safe and they can easily corrupt your RM database. Because it is so simple, an SQLite query to merge fact types is quite safe even though it is changing things. There are really only two things to worry about.
One thing to worry about is to be sure that you are changing the correct fact type to the correct other fact type. You are not actually merging anything. You would need to delete the second fact type yourself from the RM user interface after your SQLite query has run.
The other thing to worry about is to be sure that the two fact types you are “merging” are set up exactly the same with sentences, roles, where the facts can be used, etc.
I very much support the idea of being able to do the merge of fact types from within the RM user interface. It should be a very easy thing to program. The user shouldn’t have to use SQLite. And the user shouldn’t have to export the database to GEDCOM, edit the GEDCOM, and re-import the GEDCOM into another database. In fact, using GEDCOM also runs a risk of data corruption. A GEDCOM export/import cycle that is to and from RM can lose data.
Completely agree with TheJerry. I had a similar situation just days ago (I’m a new RM user) where I had thousands facts that were using custom fact types, but were duplicates of the standard ones: Birth, Marriage, Death, Burial, etc. I haven’t touched SQL in a decade, but was able to get quickly up to speed and merge thousands of events/facts back into their standard ones…within minutes.
Each duplicate can be merged with two simple lines of SQL (repeat for each duplicate type, such as Birth (std) - Birth (custom):
UPDATE sometable SET EventType = 1 WHERE EventType = 1798 ;
DELETE FROM someothertable WHERE FactTypeID = 1798 ;
Custom events have FactTypeID > 1000, and the standard RM ones < 1000. So this example takes a custom fact 1798 and turns it into the standard event 1, then after that, removes the custom fact type from the list of available fact types.
That being said, DO NOT do this unless you are 100% comfortable with your abilities, AND made a database back up before starting. The above is just an example and is not intended to be used as-is. In fact, I’ve changed it slightly so that it’s not usable as-is, so you don’t get yourself into trouble. If you learn enough about SQL and the RM database, you’ll know what to change and how.
Just in case you, or someone else reading this, feels comfortable with doing/learning this, I’ve given you a head start.
Leverage your rusty SQL with 100’s of scripts for RM and info on the database structure and definitions. We have a discussion forum there, also, for SQLite users to trade code without bothering the masses.