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:

1. 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.
2. The DNA fact type
3. 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.
4. Custom default sentence templates for built-in Fact Type roles, i.e., Principal, Witness, …
5. Fact Notes for non-Principal participants of shared events that differ from the Note for the Principal.
6. 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.
7. Standardized Place Name and Abbreviated Place Name
8. Unused:
   1. Custom fact types
   2. Custom roles
   3. Sources
   4. Custom Source Templates
   5. Repositories
   6. Places
   7. Place Details
   8. Media
   9. General Research logs do not transfer. You can use Import lists to import them. (Research logs linked to a person are transferred.)
   10. General ToDo items do not transfer. Use Import lists to import general ToDo items. (ToDos linked to a Person are transferred.)
9. The “Not a match” flags that preclude Duplicate Search Merge from offering a pair of people as a potential duplicate.
10. The “Not a Problem List” from Tools > Problem List
11. Non-default settings under Tools > File Options
12. Last-used Report settings
13. Custom report definitions
14. Publisher Book definitions
15. 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.
16. 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:

1. “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:

1. 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:

1. 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.
2. Duplicates of Custom Source Templates used by Sources already transferred, leading to
3. Duplicates of Sources using a duplicated Custom Source Template

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!

1. Delete Phantoms – a more comprehensive process than RootsMagic’s Database Tool
2. 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.

And the Group Extract is the less lossy method for Partial Transfer to an Empty Database and for duplication-free Multiple Transfers from One Database to Another.

That leaves Transfers to a Non-Empty Database without an alternative. That is a development in progress which may yet see the light of day, given enough time and skill…