That RM can transfer so much of its app specific data via GEDCOM (with RM extras) is amazing. But here we have another RM feature that isn’t transferred.
I seem to remember a list at SQLiteToolsForRootsMagic that compiled types of information lost when data is transferred via GEDCOM/DragNDrop.
Seems like there is a new items to add.
Here is a possible item to add to the list. On a drag and drop to a new and empty database, RIN numbers are not retained. If instead you do a GEDCOM export/import to a new and empty database, File => Import has an option to retain RIN numbers. The RIN retention option is available only when the target database is new and empty. Drag and drop to an new and empty database does not turn this option on, even when the target database is new and empty.
Experienced RM users routinely advise new RM users not to depend on the constancy of RIN numbers and not to organize paper or electronic records according to RIN numbers. But many RM users still seem to depend on the constancy of RIN numbers.
A drag and drop also does not provide the opportunity for the user to set File => Export options. I have always assumed the following.options File => Export options are set by drag and drop.
On Notes
On Sources
On LDS Information
On Addresses
On Tasks
On Multimedia links
On Note formatting (bold, etc.)
On Extra details (RM specific)
Off Privatize living people
On Include private facts
On Include {private} notes
Off Strip {} brackets
If my assumptions about these settings are correct, then there should be no additional losses because of the File => Export options used by drag and drop. But the drag and drop documentation doesn’t address these settings.
Jerry, your note surprises me. For me the best way to organize paper and electronic record is to keep a ID number for each person and RIN is good for this purpose. I don’t know how this will be done without any ID number for database with 20 thousand people and let say 5 John Smiths with the same date of birth. For me RIN is like SSN. Normally is better to work with numbers rather than acronyms.
But what happens when the RIN numbers in RM change? Experienced RM users always recommend filing paper and electronic records by some other mechanism than by RM RIN numbers.
You’re right about the field usage. I’ve known those settings aren’t preserved since my early days with RM but haven’t made it explicit in the list which probably needs an update about TreeShare, too.
As for fact type sentences, that"s listed:
“5. Custom default sentence templates for built-in Fact Type roles, i.e., Principal, Witness, …”
That would be why you have a built in Ref# field. It remains the same regardless of what else you do. It is meant for precisely the purpose you described.
One possible solution would be for the program to copy the RIN to the Ref# when a new person is entered. However, people who like to have a specially constructed alphanumeric format for Ref# would have to be accommodated by not copying the RIN if a Ref# is already entered for the new person. If the user does not enter a Ref# as part of the info for a new person, they can still change the Ref# if their needs are different or change later. This procedure would require interface changes to allow the Ref# to be entered as part of the person’s original info instead of later as a fact. The program already does this by automatically adding birth, death and other facts from the person entry screen for a new person.
I think the idea has merit but would need the added requirement that, because multiple Ref#
facts are allowed per person, this Ref# would need to be designated Primary and that it is the Primary one that is displayed after the name. Or some new non-volatile record/reference number field needs to be defined in the database structure.
Iirc, RM7 allowed additional fact types in the Add Person dialogue. My computer is not in front of the Super Bowl screen so I’ve not checked whether RM9 does, too.