Logo Home    Page list

GEDCOM & DnD transfer losses #gedcom

Table of Contents

Background
"Full" Transfer to an Empty Database
Partial Transfer to an Empty Database
Multiple Transfers from One Database to Another
Alternative Transfer Methods

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. Unused:
    1. Custom fact types
    2. Custom roles
    3. Sources
    4. Custom Source Templates
    5. Repositories
    6. Places
    7. Place Details
    8. Media
    9. Research Logs? (clarify, + are there RLs that don't transfer at all?)
    10. To Do items? (clarify, + are there TDs that don't transfer at all?)
  8. The "Not a match" flags that preclude Duplicate Search Merge from offering a pair of people as a potential duplicate.
  9. The "Not a Problem List" from Tools > Problem List
  10. Non-default settings under Tools > File Options
  11. Last-used Report settings
  12. Custom report definitions
  13. Publisher Book definitions
  14. FamilySearch?
  15. TreeShare?

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

Discussions

ve3meo

Observations from Laura Beeman

ve3meo 21 September 2018 19:48:58

Tom, on your list on that web site.

9. General Research logs do not transfer. You can use Import lists to import them. Research logs linked to a person are transfered.

10. General ToDo items do not import. ToDos linked a Person are transferrd. Use Import lists to import general Research logs.

14.. The Family Search ID is inported. 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.

15. If the database you are dropping from into a new database is linked to an Ancestry tree, the new database will also be linked to the same Ancestry tree.

www.000webhost.com