Jump to content


Photo

Need to "Merge" Fact types

fact types

  • Please log in to reply
4 replies to this topic

#1 rschreff

rschreff

    Member

  • Members
  • PipPip
  • 8 posts

Posted 22 June 2018 - 06:22 PM

Been using RMG since about 2005, I can't remember when I had to go to this extent to write here....

My database now has over 42,000 individuals, over the years, large chunks have come in via trusted GEDCOMs, apparently, in other software they are also allowed to make custom fact types....so when I merged their GEDCOMs into mine, their custom fact types also came along...the annoying part is that they are so close in name to the inherent RMG fact types, that it now clutters up my fact type selection list...best would be able to merge these rogue alien fact types with the RMG ones, just like when I merge places in a place list that seems redundant etc....then, to make it even better, is to somehow highlight which fact type is native to RMG, maybe make it bold in the list, so that the alien fact types stick out and I can then do a merge...

 

Am I off base here or have I found a useful merge?

 

Thanks for the help.



#2 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5857 posts

Posted 22 June 2018 - 08:01 PM

Merging (or bulk conversion) of fact types is an enhancement request of longstanding as is making custom fact types distinct from built-in ones. 

 

In RM7, the only way to change an event from one fact type to another is by one event per person at a time in the Edit Person window. To make bulk changes, you could:

  • export a GEDCOM and use a text editor to globally search and replace a custom event name with a standard one
  • use SQLite to directly update the EventTypeID in the EventTable 

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a bundle of RootsMagic utilities.


#3 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3183 posts

Posted 25 June 2018 - 06:01 AM

Am I off base here or have I found a useful merge?

 

As TomH said you have hit upon a much needed facility within RM although development may be avoiding it due to the potential for mishaps, no matter how many warning dialogues some users will just click through regretting it later.

 

Also your experience with almost same fact types or users creating a custom fact where a standard one would be perfect is something I come across often. What I do firstly is is to customize the People tab to include the fact type in question Date, Place, Place Detail and Description and then create a Group where this fact type exists. I scroll the list and tidy where appropriate so the data matches my standards, then I change the fact type with SQL as TomH mentioned.

 

The other problem where I do not see a concern for RM is where you have imported a gedcom with for example a Birth date with Year only or an approximated Date whereas you lated merge with an individual in your file which has an exact birth date. The merged individual in your file will now have TWO Birth facts due to the slight difference in the date. There are slightly protracted ways of isolating these for correction but I believe a utility within RM to help clean these up is very much needed incorporating a Merge utility so the user can choose what to keep on the merged event.


If one accepts second best then quite often that's just what one will receive

— Dag Hammarskjold

 

Current user of Rootsmagic version 7.5.7.0, Family Tree Maker 2014 and Legacy 7.5 on Win 10

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#4 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1356 posts

Posted 25 June 2018 - 06:46 AM

 

Merging (or bulk conversion) of fact types is an enhancement request of longstanding as is making custom fact types distinct from built-in ones. 

 

In RM7, the only way to change an event from one fact type to another is by one event per person at a time in the Edit Person window. To make bulk changes, you could:

  • export a GEDCOM and use a text editor to globally search and replace a custom event name with a standard one
  • use SQLite to directly update the EventTypeID in the EventTable 

 

 

Another workaround to "merge" fact types:

 

1 -- Go through the Fact Type list and edit all of the duplicates to match the built-in (or preferred custom) Fact Type. As with Repository merging, match everything - name, abbreviation, usage, sentences, etc.

2 -- Do a GEDCOM or drag-n-drop to a new database.

3 -- In the new file, you'll find the Fact Type merges have taken place.



#5 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3060 posts

Posted 25 June 2018 - 08:13 AM

 

Another workaround to "merge" fact types:

 

1 -- Go through the Fact Type list and edit all of the duplicates to match the built-in (or preferred custom) Fact Type. As with Repository merging, match everything - name, abbreviation, usage, sentences, etc.

2 -- Do a GEDCOM or drag-n-drop to a new database.

3 -- In the new file, you'll find the Fact Type merges have taken place.

 

Here is another variation on the same theme. I don't use RM's standard, built-in census fact type. The reason is that there are some limitations that I don't like in the way RM handles multiple facts of the type for the same person. For example, multiple facts of the same type for the same person make it essentially impossible to make use of that fact type in People View or to do accurate searches (or markings and unmarkings for groups) against that fact type. So I have a fact type called 1850 Census that I use for the 1850 census, I have a fact type called 1860 Census that I use for the 1860, census, etc. This completely solves RM's problems with putting census facts into People View and RM's problems with searching for census facts.

 

Rather than changing thousands (maybe tens of thousands?) of census facts by hand, I ran an SQLite script developed by Tom to change all my census fact types as required. A data element that RM stores for each fact type is the GEDCOM tag that should be used for GEDCOM export - BIRT for the birth fact, DEAT for the death fact, CENS for the census fact, etc. So Tom's script maintained CENS as the GEDCOM tag for all my "yyyy Census" fact types. Therefore, if I wished to do so I could drag and drop my database and all the census fact types would be restored to default. That's because a drag and drop uses GEDCOM for data transfer to the new database. Or I could run another one of Tom's scripts to restore all my census fact types to default. I would probably do the latter because I'm so suspicious of what data might get lost in the GEDCOM used for a drag and drop.

 

Even though the GEDCOM tag to be used for GEDCOM export is stored in RM's Fact Type table, it is not visible or editable from RM's user interface. It might be dangerous to expose it to the user interface, but doing so could be very useful at times.

 

Jerry