* Retaining RIN Numbers Exporting to RM8

[Voltface]

Can anyone help?
I have Family Historian 7 (Main genealogy programme) on my PC and Roots Magic 8 on my Mac. I would like to export my FH data to Rootsmagic, retaining the same numbering (RIN).
Roots Magic should when importing a GEDCOM file to an empty database give the option to maintain RIM numbers but this tick box does NOT appear when importing directly from my Family Historian database (which I beleive is the recommended process). The file imports successfully but the RIN is changed.
If I instead I export a GEDCOM file from FH7 and then import this into Roots Magic, the file processes but the RM database remains completely blank. It is the same result if I use Rootsmagic 8 PC or MAC version.
I have contacted RM8 team and they can not suggest a solution.
I can see in 2016 the forum discussed the same issue in regard to a plugin but this appears irrelevant to the FH7.
Has anyone successfully imported from FH7 into RootsMagic 8 keeping the same RIN?
Thank-you for your time.

[tatewise]

Welcome to the FHUG.

Please confirm that your FH Project does actually have RIN (Automated Record Id) assigned to Individuals.
They are not generated automatically by FH and cannot be added manually by users.
They only exist when imported from another genealogy product and are usually only shown on the All tab.
They are very different from the Record Id often shown in square brackets in FH.

That probably explains why they don't import into RM8, i.e. they don't exist in FH.

BTW: I'm a little mystified why importing the FH Project GEDCOM works, but importing an exported GEDCOM does not.
Exactly what command options did you use?
A better alternative is the Export Gedcom File plugin that adjusts the GEDCOM data to suit RootsMagic better.

[kfunk_ia]

Roots Magic should when importing a GEDCOM file to an empty database give the option to maintain RIM numbers but this tick box does NOT appear when importing directly from my Family Historian database (which I beleive is the recommended process). The file imports successfully but the RIN is changed.

First of all, RM has never prompted you to keep RIN numbers on GEDCOM import to the best of my knowledge and I have been using RM since it was Family Origins

Secondly, RM does not have an option to directly import FH files, so if you are trying to directly import the core GEDCOM file that FH uses, you are likely going to loose bits and pieces that are store in the project files. You should really be using the plugin to export a GEDCOM file specifically for RM.

Thirdly, I really wish users would use their own reference numbering system and stop trying to use and expect the RIN to move with and to stay the same all the time. RIN is an internal reference number not meant for human consumption Various programs deal with them differently.

[Voltface]

RootsMagig 8 does have a RIN retention option. Roots Magic help desk insist the RIN retention option should be offered as a tick
Box with all gedcom imports into empty RM8 databases but this is certainly not my experience on both the pc and mac version. I have sent them screen prints to prove it! They have sent me screen prints showing the option!
I use simple generated unique sequential IDs and need them to remain fixed between gedcom programmes. This does not seem a big ask of a genealogy programme import/export process. Personalised reference number systems i have found create more difficulties than they solve but its a personal choice. My numbers were bought over from Brothers Keeper in the 1990’s so i am not changing now!
Family Historian’s guide says “You do not have to convert Family Historian Files to the gedcom format. They already are in the Gedcom format.”. Some advise to try importing the database directly. Simply opening the file up directly in Rootsmagic has indeed produced the best import to date for me to date and i have tried a few options, presumably because i use a standard database without bespoke changes which i think is always good database practice.
The only problems to date are the RIN and Media links (i have a mix of internal
And external media) which i can see from other posts is a known problem i am also working on!
Following the helpful comments from users i copied my Family Historian id into the custom field and will try to retain it that way.
I have also installed the Export Gedcom v5 plug In which i had thought had been superseded by later versions of FH so very grateful for that advice too. I will let u know how i get on with this.
Thank- you everyone

[tatewise]

Please confirm that your FH Project does actually have RIN (Automated Record Id) assigned to Individuals.
They are usually only shown on the All tab of the Individual Property Box, and cannot be edited by users.
You probably already know this but they are different from Record Id, Custom Id (REFN), Permamanet Record Number, FamilySearch Id, and Unique Id.

The problem with Media is likely to be due to a difference in GEDCOM specification.
The FH Project GEDCOM uses GEDCOM 5.5.1 whereas I think RootsMagic uses GEDCOM 5.5 and the Media format differs.
File > Import/Export > Export > GEDCOM File... defaults to GEDCOM 5.5.1 but Destination: Family Historian 6 uses GEDCOM 5.5 and so does the Export Gedcom File plugin with destination set for RootsMagic. However, the plugin converts RIN values to custom facts so won't help with that data.

[Voltface]

Hi Mike, sorry the terminology I was using (it seems incorrectly) was Record Id Number (RIN) as displayed in Family Historian in brackets. I have never used the Family Historian ARI (Automated Record Id) or the Unique Record Id (URI). The Custom no. I have used occasionally to reconcile to other folks numbering.
As I do not delete any record number and have never renumbered my database I have managed to keep this unique Record ID the same for all entries on my data base for the last 30 years without any problem! I use these numbers in all my paper files as well as other databases & speadsheets. Keep it simple is my motto.
It is this FH "Record ID" number that I want to bring across as a new permanent Id Number. I have never used Roots Magic before and have yet to explore it but it appears to let you choose between an "assigned number" chosen by RM8, a REFN number which can be added by the user, or the Family Search ID.
I therefore need the Family Historian ID Number or the FH Custom No. to be imported as the RM8 assigned number (preferably) or the REFN number?
Hope this make sense now.
Regards

[KFN]

From a GEDCOM v5.5.1 perspective here are a few definitions.

XREF (xref_id):

The xref_ID is formed by any arbitrary combination of characters from the pointer_char set. The first character must be an alpha or a digit. The xref_ID is not retained in the receiving system, and it may therefore be formed from any convenient combination of identifiers from the sending system. No meaning is attributed by the receiver to any part of the xref_ID, other than its unique association with the associated record.

Some software call this the ‘Record ID’, some wrongly call it a RIN. This value in most software begins with a single letter like an ‘I’ for individual, ‘S’ for Source. These numbers only have importance with the current system and may be changed when a GEDCOM transfers your database to a new system. In my opinion it should never be used in an external filing system.

RIN:

AUTOMATED_RECORD_ID:= {Size=1:12}
A unique record identification number assigned to the record by the source system. This number is intended to serve as a more sure means of identification of a record for reconciling differences in data between two interfacing systems.

. Some systems generate this automatically and very often this is the same as the xref_id, but not always.

REFN:

USER_REFERENCE_NUMBER:=
A user-defined number or text that the submitter uses to identify this record. For instance, it may be a record number within the submitter's automated or manual system, or it may be a page and position number on a pedigree chart.

I personally use this value as my cataloging value to paper and photo archives in my personal library. The value I generate is similar to the accession numbers we generated at the museum where I once worked and is unique to all sources, media, and individuals in my GEDCOM.

Other ids like the RFN <PERMANENT_RECORD_FILE_NUMBER> and AFN <ANCESTRAL_FILE_NUMBER> are generate by outside systems and are most likely added by hand in a desktop application

If you don’t explicitly have an actual RIN or REFN tag in your GEDCOM the xred_id can and may be changed on import into a new system.. Some applications use different terms for GEDCOM tags with these definitions, this is why I have defined them here using GEDCOM names and definitions.

[tatewise]

OK, so we are not discussing Automated Record Id but the Record Id shown in [ square brackets ] all over FH.

Those Record Id import unaltered to most products, including RootsMagic, without needing any option settings.
That is because they are the fundamental record numbering identity specified by GEDCOM.

Confusingly, RootsMagic refer to the Record Id as the RIN (which is the GEDCOM tag for Automated Record Id).

In RootsMagic 8, the Settings option Number to Display can be None, RIN, REFN or FSID.
If RIN is chosen then the Record Id = RIN is shown after a hyphen following each person's name.
e.g. John SMITH-32
Whereas in FH it would display as John SMITH [32]

[kfunk_ia]

I use simple generated unique sequential IDs and need them to remain fixed between gedcom programmes. This does not seem a big ask of a genealogy programme import/export process. Personalised reference number systems i have found create more difficulties than they solve but its a personal choice. My numbers were bought over from Brothers Keeper in the 1990’s so i am not changing now!

If you are generating them, they are not RIN numbers. In RM an RIN number is autogenerated when a person is added to the database and it is the primary key to the PersonTable. The column is PersonID. One does not reuse primary keys in a relational database.

[tatewise]

As I explained, they are what RootsMagic mistakenly calls RIN numbers but are actually Record Id that are unique IDs generated by FH (although they are not necessarily sequential if records get deleted).

[kfunk_ia]

You don't need to be condescending Mike. I am quite well aware of what you said and I wasn't addressing you. As for RM doing something "mistakenly" that is your opinion. RM is specifically calling them RIN numbers for a purpose because in the overall scheme, that is precisely what they are. What FH decides to do with them is a different issue.

[KFN]

RM is specifically calling them RIN numbers for a purpose because in the overall scheme, that is precisely what they are. What FH decides to do with them is a different issue.

The problem here is that by RM calling an xref_id a RIN they confuse the heck out of GEDCOM imports that actually have a RIN tag that is not equal to the xref_id. When RM is in their own little bubble they can call fields whatever they want, but when generating and receiving a GEDCOM they must adhere to the definitions documented by GEDCOM.

By definition the xref_id could be a 20 digit GUID or a word like ‘John’, so long as it is unique and starts with a letter or number. This is similar to a non-user data dbkey in CODASYL, Which is different than a Relational database foreign key which is very often user data.

[Voltface]

Good news, as discussed I have created a custom number in FH (a duplicate of the generated number) and imported to RootsMagic 8 using different options. In RootsMagic 8 Under settings you can choose the "Number to Display" which offers three numbering protocols for the empty project. The options are None, RIN, REFN, FSID.
Using the REFN number and importing directly from the Family Historian database now creates a new Rootmagic 8 database with the FH Custom Field displayed as the default number which i what I was hoping for!
Thank-you for leading me to this solution which I hope might be helpful to others.
Now to sort out the media links!
For information RootsMagic team also emailed me today and following my screen print evidence the team has tested the Gedcom import function and confirm that the "RIN" option (Rootsmagic Terminoiogy for ID number) only appears for RootsMagic and Personal Ancestral File and not any other file!
Thank-you again for all your help

[kfunk_ia]

The problem here is that by RM calling an xref_id a RIN they confuse the heck out of GEDCOM imports that actually have a RIN tag that is not equal to the xref_id. When RM is in their own little bubble they can call fields whatever they want, but when generating and receiving a GEDCOM they must adhere to the definitions documented by GEDCOM.

By definition the xref_id could be a 20 digit GUID or a word like ‘John’, so long as it is unique and starts with a letter or number. This is similar to a non-user data dbkey in CODASYL, Which is different than a Relational database foreign key which is very often user data.

xref_id and RIN have nothing to do with each other. xref_id are the numbers that link the families/source and so on together. The RIN is simply a primary key in the PersonTable in RM. It was the same thing in FTM before MacKiev encrypted their database and hid it from their users. Family Origins used the RIN concept as does Legacy, and it has been a long time but I believe Ultimate Family Tree did also. All have some form of relational database behind them. FH is only immune because it does not have a relational database behind it, choosing to instead use the GEDCOM format.

Anyhow, this all goes back to my original assertion that people need to stop using the RIN numbers for anything, they are not reliable between software packages. The OP seems to have decided to do just that with his usage of a custom ID that is the same as his RIN numbers. He will probably be ok as long as he goes back and forth between FH and RM, but all bets are off it he ever goes outside of the eco-system, or even if he deletes a record.

[tatewise]

IMO as long as he uses the Custom Id (REFN GEDCOM tag) his reference numbers should remain consistent in all products that support the Custom Id concept. That data field should be independent of the RM RIN, the FH Record Id, GEDCOM xref_id, etc.

Choosing to show the RM REFN against Individuals in no way involves the RIN which is an entirely separate identity.

Similarly, the FH Custom Id (REFN) is entirely independent of the [ Record Id ].

The same goes for many other products that I am aware of.

BTW: I believe the Media issues are caused by the GEDCOM 5.5 versus 5.5.1 differences, so use Export > GEDCOM File... with Destination as Family Historian 6 (which uses GEDCOM 5.5) and the Media should be OK.

[Mark1834]

That's my experience, as I originally developed my system for Individual custom IDs way back pre-computer use, and they have transferred seamlessly between several packages over the years.

The same can't be said for Family IDs. I originally included them in my Ancestry sync plugin, but they do not transfer cleanly between FH, RM, and ANC. I think Ancestry was the problem and treated them as a custom fact. There might have been a workaround, but I ended up deleting them completely, as they weren't adding any value to my records.

[KFN]

Kfunk_ia said:

xref_id and RIN have nothing to do with each other.

Exactly what I implied, yet RM uses the term RIN to represent the same value in their discussions.

And also said:

Anyhow, this all goes back to my original assertion that people need to stop using the RIN numbers for anything, they are not reliable between software packages.

It can be used If software companies stop using the term RIN (an actual GEDCOM tag) to be their SQL foreign keys.

In GEDCOM the RIN tag is defined as:

AUTOMATED_RECORD_ID:= {Size=1:12}
A unique record identification number assigned to the record by the source system. This number is intended to serve as a more sure means of identification of a record for reconciling differences in data between two interfacing systems.

[KFN]

That's my experience, as I originally developed my system for Individual custom IDs way back pre-computer use, and they have transferred seamlessly between several packages over the years.

The same can't be said for Family IDs. I originally included them in my Ancestry sync plugin, but they do not transfer cleanly between FH, RM, and ANC. I think Ancestry was the problem and treated them as a custom fact. There might have been a workaround, but I ended up deleting them completely, as they weren't adding any value to my records.

Speaking only in GEDCOM terms and using GEDCOM as your data transfer process, “Family ID” is not a value in the specification! However, very often the term “Family ID” actually is referring to the internal foreign key that the sending system uses to connect record instances and is no different than in GEDCOM what we call an xref_id. If true, this value should never be relied on as permanent identifier between systems because it (an xref_id) can be changed to any value by the receiving system. Too often stand alone applications think only in terms of their own environment when defining terms and building a GEDCOM, this is why transferring data between applications (aka systems) using GEDCOM requires some manipulation to get the data right in the receiving application!

[Mark1834]

Loose language on my part - I was referring to Family Custom ID, which is defined in GEDCOM.

[KFN]

I don’t see a tag in the GEDCOM v5.5.1 Standard called “Family Custom ID”.

The only tags that could be an “ID” is the REFN and RIN tags.

I use exclusively the REFN tag for my external cataloging system, since it is the only value I can control, while the RIN is solely controlled by the system.

[tatewise]

Almost every type of record offers a REFN Custom Id field.
So I think Mark is referring to the Family record Custom Id field, i.e. FAM.REFN as defined in all recent GEDCOM versions.

[KFN]

Almost every type of record offers a REFN Custom Id field.
So I think Mark is referring to the Family record Custom Id field, i.e. FAM.REFN as defined in all recent GEDCOM versions.

Got it, thanks. Different terms for the same field.