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.)
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.
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)
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.
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…
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.
I just tried to drag a spouse over to a database where I had all the children, but didn’t have the father. I checked the box to make sure he is added as spouse which should also link him to the children. Well the first time I did it I only copied him over. He is not listed as the father. did the drag and drop a second time and selected to bring over descendants, 2 generations. Seems to have duplicated some of the children. Did a third drag a drop with just 1 generation and he is listed with all the children, but has no spouse (who was already in my database). Dragging with more than just the person seems to duplicate the descendents.
RM10.0.1 on Windows 11
Right. Using drag and drop to fix a missing parent is a complicated scenario. The list in this thread assumes a drag and drop into a new database.
I believe the only way to avoid duplicating people in the scenario you describe would be to drag the male parent and then manually link them to the existing family. Also, Family facts, like marriage, would need to be recreated manually with that approach. The RM10 help doc for drag and drop notes " Family facts are only transferred if the couple sharing those facts are dragged together to the other database." This was the case in prior releases as well.
Drag and drop with descendants and their spouses with generation = 1 should get husband and wife with all of their family facts. If generation = 2, that should include children and any of their spouses. Then you’d need to merge duplicate people.
When you drag n drop a person into a relationship spot you need to check the box at the bottom of the Drag and Drop screen to confirm you want them added in that relationship. With mother and children and no father you would drag n drop the father onto the Add Husband spot on the Family View. Then confirm the person is the husband of (mother) by checking the box at the bottom.
You will have a lot of clean-up to do with all the duplication you just added to your database. It’s best to restore a backup at this point and start over to do the drag n drop correctly.