RM 10 Drag and Drop findings

The Drag and Drop feature has been enhanced in RM10. It no longer is a gedcom export/import, however there is still data loss in some areas.

This post is intended to generate a discussion of what is and what is not preserved with the new RM10 Drag and Drop feature.

The list below is based on the Drag and Drop of an entire RM v10.0.1 db to a blank RM db.

Drag and Drop does xfer:

  • Individuals, Families and Events (including Shared Facts)
  • Used: FactTypes, Places, Place Details, Sources, Citations, Media, Media Links, Tasks, Associations, Tasks (and Task Folders), Addresses, and Repositories
  • DNA Facts, DNA Matches, and Health Conditions
  • Treeshare connection to Ancestry (added with v10.0.1)
  • FamilySearch ID (added with v10.0.1)
  • Set Relationship setting
  • Custom Roles for a Fact Type
  • Customized footnote for a citation
  • Last used report
  • Trailing white space at the end of all Note type fields
    [edit: test indicates white space characters transfer but file compare is at 99% vs 100%]

Drag and Drop does not transfer:

  • Unused: Sources, Places, Place Details, Media, Tasks, Repositories, Addresses, Labels for Color Code Sets (All can all be imported granularly via File > Import Data > Import Lists.)
  • Ancestry Table or FamilySearchTable
  • DNA Match, when missing a person
  • Associations, when missing a person
  • Report settings (Custom Reports can be imported granularly via File > Import Data > Import Lists.)
  • Saved Books
  • Home person (gets set to rin=1)
  • The “Not a match” flags from Tools > Duplicate List
  • The “Not a Problem List” from Tools > Problem List
  • [edit:] RIN numbers (RINs get assigned sequentially in the target db, starting with RIN=1, and no RIN numbers are skipped. So any gap in RIN numbers within the source db will result in RIN mismatches for all subsequent people moved into the target db. Note that PersonTable.UniqueID is preserved.)
  • [edit:] Saved Searches
  • [edit:] Groups
  • [edit:] Edits to standard FactTypes
  • [edit:] Unused custom FactTypes
  • [edit] Date Edited column, available in the People List view, is overwritten with the date of the drag and drop. (Similarly, UTCModDate table values are updated to the drag and drop date.)
3 Likes

Are the RIN numbers preserved?

They can be preserved with GEDCOM export/import, but they are not preserved in any drag and drop previous to RM10.

No, good catch. RIN numbers are not preserved. I’ll update the list.

Did you D&D by selecting the RIN #1 person?

1 Like
  1. groups are also not transferred

  2. a) Treeshare connection to Ancestry and FamilySearch ID
    were transferred in former RM versions RM9, RM8, … I wonder why this was changed??

    b) Treeshare connection to Ancestry and FamilySearch ID are still transferred by export to gedcom and import to a new database. So there are data that are lost in both processes. But the data loss of no process is a subgroup of the other process.

1 Like

Great question. As a caveat, I’ve only tested a drag n drop of “everyone in the database” moving into a blank db, so I can’t say how the process works in all cases. For this drag and drop option, the process seems to always move people from lowest RIN to highest RIN. The RIN of the person initially dragged didn’t impact the order that people were copied. Rather, the cause of RINs not being preserved is that RINs get assigned sequentially in the target db, starting with RIN=1, and no RIN numbers are skipped. This makes sense, however it also means that any gap in RIN numbers within the source db will result in RIN mismatches for all subsequent people moved into the target db. (I’ve added this additional text to the list above)

1 Like

Thanks, I missed that. Added to list above.

Great question. Perhaps it was oversight and will get added back in since (at least Ancestry) can’t be recovered through the user interface. I was hoping that the AncestryTable and FamilySearchTable would be moved as well but that hasn’t happened.

I don’t do much with gedcom files. Have you explored whether the API connection details can be isolated and restored via gedcom export/import into an existing db?

It seems to me that any implementation of drag and drop has one peculiar challenge, no matter if it is accomplished using GEDCOM as the transport mechanism or whether it is accomplished by copying database records directly. Namely, there is fundamental difference between copying a database in its entirety to a new and empty database on the one hand and copying all or part of a database to an existing database that is not empty.

As one of many examples, it’s at least theoretically possible to maintain RIN numbers when dragging and dropping to a new and empty database but it’s not even theoretically possible to maintain RIN numbers when dragging and dropping to an existing database that is not empty. It’s not just RIN numbers. There are all kinds of collisions and conflicts that are possible when dragging and dropping to an existing database that is not empty.

I’m not sure what my point is exactly, except that both the developers and we the users need to think about what drag and drop is trying to accomplish when dragging and dropping into a new database vs.when dragging and dropping into an existing database. In a perfect world, there would be little reason to drag and drop into a new database. You would simply copy the old database. In this case, no data would be lost, no API connections would be lost, etc. But sometimes a drag and drop is suggested precisely because you want to lose some data, namely you want to lose some data that is either corrupted or that is no longer used. So sometimes there can be value in dragging and dropping into a new database rather than just copying the whole file.

And on the other hand, dragging and dropping into a database that is not empty is intended primarily to combine data from multiple databases. It’s really just a shortcut for a GEDCOM export/import. In this case, you are not wanting to lose corrupted data or lose unused data. And you are not trying to copy groups or things like that. You are simply wanting to copy all the data for a collection of people without losing any of the data that’s specific to those people.

1 Like

I agree that when transferring data from one database to an empty database, the reason often is to get rid of some kind of corruption in the database.
To my impression the need to do so was more frequent with RM7 compared to Rm8, …,RM10, so the handling of the SQL database seems to have improved.

But exactly in this situation, I think it would make more sense to have 2 processes of rising strictness. That means, for example, the gedcom export/import looses most data but cleans best a corrupted database. The drag/drop on the other could transfer more items but does not clean corrupted databases as good as export/import by gedcom.
But this is not the way the 2 processes are designed.

I was not aware that new RM10 D-n-D method re-assigns RIN;s sequentially. I wish it allowed maintaining them although I partly understand the logic of not. Thanks for pointing that out.

Thanks for doing this @kevinm – the one thing I noticed is that IF you CUSTOMIZED a basic fact ( marriage/ death/birth—one that can NOT be deleted)-- the Customization is not transferred on a drop and drag-- I customized the marriage fact by checking description and adding desc to the sentence-- like a gedcom, it was NOT transferred-- you have to go back in and check desc and then add it to the sentence and you info will reappear-- exactly what we were doing with gedcoms and RM 9…

Kind of interesting as when I converted the database from RM 9 to RM 10, it did include the customization which did NOT happen when I converted it from RM 8 to RM 9…

just like associations when missing a person were included in the conversion from RM 9 to RM 10 but not in the drop and drag…

Have updated the list above. Thanks!

I also noticed that I had omitted Unused Custom FactTypes from the list of unused items not transferred; have made that update as well.

Well said! There are several use cases for the drag and drop function and whether a specific data element is preserved may be important in one instance and undesirable (or less important) in another. I tagged the post as a “Tip” in that spirit, mainly for awareness of how the feature works and not implying a request for a feature change.

Date edited is not transferred in a D&D. That “field” is filled with the date of the D&D.

2 Likes

Thanks, added to list above.

Updated list for V10.0.1 release enhancements to preserve the AncestryTable and FamilySearchTable.

Update 10.0.1

  • Fixed: Drag and drop lost FamilySearch ID
  • Fixed: Drag and drop lost connection to Ancestry tree
2 Likes