Contents
Background
RootsMagic Drag’n’Drop between the windows of two databases is a background GEDCOM export-import process. Both Drag’n’Drop and the explicit File>Export and Import process fail to fully transfer everything from one database to another. Drag’n’Drop and GEDCOM are governed by the settings for Export in Lists>Fact Type List so any fact type that is not enabled for “Exporting GEDCOM files” will be lost in transfer. A number of other less obvious losses have been identified by various users over the years. A SQLite script from 2012 that is included in RMtrix, asterixed a number of items that would not transfer; see RMGC_Properties – Query The following list is an attempt to consolidate all known GEDCOM|Drag’n’Drop transfer losses:“Full” Transfer to an Empty Database
Having selected everyone in the database, the following are lost:- Named Groups definitions. (added 2020-06-04)
- Fact types not enabled for “Exporting GEDCOM files” in Lists > Fact Type List. To check and fix this in RM and then revert is tedious. The scripts on Fact Inclusion Controls and in RMtrix can help.
- The DNA fact type
- Fact Description fields longer than 100 characters either truncated or transferred to the Note. Prior discussion here predated the changes in RM to address truncation by moving the data.
- Custom default sentence templates for built-in Fact Type roles, i.e., Principal, Witness, …
- Fact Notes for non-Principal participants of shared events that differ from the Note for the Principal.
- Trailing white space at the end of all Note type fields in facts, events, sources, citations, places… and from all text fields that can export giving rise to mismatches using File Compare between original and target database and, using TreeShare, between target database and original Ancestry Member Tree.
- Standardized Place Name and Abbreviated Place Name
- Unused:
- Custom fact types
- Custom roles
- Sources
- Custom Source Templates
- Repositories
- Places
- Place Details
- Media
- General Research logs do not transfer. You can use Import lists to import them. (Research logs linked to a person are transferred.)
- General ToDo items do not transfer. Use Import lists to import general ToDo items. (ToDos linked to a Person are transferred.)
- The “Not a match” flags that preclude Duplicate Search Merge from offering a pair of people as a potential duplicate.
- The “Not a Problem List” from Tools > Problem List
- Non-default settings under Tools > File Options
- Last-used Report settings
- Custom report definitions
- Publisher Book definitions
- The Family Search ID is transferred. The FamilySearch password for FamilySearch Central and FamilySearch WebHints are imported. FamilySearch Central and FamilySearch Person Tools work as usual. You do need to check LDS Support at Tools, File options, General.
- TreeShare linkages for media and citations of Ancestry Sources are lost but the person-person TreeShare connection is maintained.
Partial Transfer to an Empty Database
Having selected a subset of the people in a database, the following are lost, in addition to the above:- “Family”-type fact types for couples broken by one not included in the selection, e.g., Marriage, Census (fam), Residence (fam), Separation, Divorce and anything that becomes “unused” as a result.
Transfer to a Non-Empty Database
Whether full or partial, the following are lost, in addition to the above:- TreeShare connection
Multiple Transfers from One Database to Another
In addition to the losses attendant to transfers, multiple transfers from one database to an initially empty database have the following undesirable outcomes:- Duplicates of people if already transferred; Drag’n’Drop can merge the focus person if dropped onto the duplicate.but not the others in the selection.
- Duplicates of Custom Source Templates used by Sources already transferred, leading to
- Duplicates of Sources using a duplicated Custom Source Template
Inter-version Losses
Additional losses may be incurred when transferring via GEDCOM between databases under different versions of RootsMagic. For example, no TreeShare data exported from RM7.5+ can be imported by earlier versions. No Tasks and Task Folders from a RM8 GEDCOM can be imported by earlier versions.Alternative Transfer Methods
As an alternative to “Full” Transfer to an Empty Database, one might simply make a copy of the database, using RM’s File>Copy. That is simply copying the file by the operating system and does nothing to clean out detritus and perhaps repair certain problems that a GEDCOM|Drag’n’Drop transfer may do as is routinely advised by RootsMagic staff. Bad data is bad data and there can be corruption that can go undetected by the File >Database Tools set and only surfaces in a GEDCOM export with a crash. Then it’s too late for the transfer to fix anything. Better to add a regular “full” GEDCOM export to your routine to monitor for such corruption so that you can revert to a recent uncorrupted backup (you are doing them frequently?). But what about the detritus from intensive database operations? We have SQLite solutions!- Delete Phantoms – a more comprehensive process than RootsMagic’s Database Tool
- Groups – Extract most everything for one to a new database – a group of “Everyone in the database” loses only the stuff “unused” by any of the people.
- Direct Import of RM8 database into RM7 – Part 1 – a direct inter-version transfer, detritus and all, except for some things.
Updated observations on loss of TreeShare linkages for media and citations of Ancestry Sources and incorporation of Laura Beeman’s comments of 21 September 2018.
Additional losses may be incurred when transferring via GEDCOM between different generations of databases. For example, no TreeShare data exported from RM7.5+ can be imported into earlier versions. No Tasks and Task Folders can be imported from RM8 into earlier versions.