12 replies to this topic

[TomH]

On a GEDCOM import into a new,empty database, we are given the option to Preserve record numbers. This works for what is commonly called RIN but not for MRIN, respectively PersonID and FamilyID in RM's internal tables. Therefore, this feature is half broken, especially for those users accustomed to using them with external filing systems.

For a drag'n'drop transfer to an empty database, there is no option to Preserve record numbers of either kind. Given that it is available for the GEDCOM import, there is no reason for it not to be available for drag'n'drop, underlying which is a GEDCOM export and import.

If the transfer is into a non-empty database, the feature is not offered at all; a desirable enhancement would be a best effort to Preserve record numbers where possible and possibly another option to Offset record numbers by some user selectable constant, e.g., 1000, that would shift the imported numbers by that amount to avoid conflict and to facilitate followup finding, editing and merging.

[Renee Zamora]

Confirming this issue is noted in our tracking system.

[bitbinder]

I just ran into this same problem. I have a Roots Magic database in which I had deleted a family. I exported the data into a GED file. The deleted family number was not listed. I imported this GED file into a new database on another computer then exported this database to a GED just to compare input vs. output. The exported file has all the families renumbered from the deleted point forward. I expected the family numbers to be preserved since I had selected preserving record IDs. I am going to have to write my own program to fix the renumbering - work I did not expect to have to do.

[kbens0n]

Preserve record numbers refers to the numbering scheme assigned (by RootsMagic) to individuals, NOT families ...for database purposes.

[TomH]

RM also assigns a record number to each couple in its FamilyTable and outputs it as MRIN in at least one report. Of course, it has many other tables, each with its own record number for database purposes but these are not made visible to the user in any way.

[TomH]

Has anyone else got this problem? "Preserve record numbers" has disappeared from my GEDCOM import dialog and, as a result, RM is assigning new record numbers. RM 6.3.1.4.

[kbens0n]

Has anyone else got this problem? "Preserve record numbers" has disappeared from my GEDCOM import dialog and, as a result, RM is assigning new record numbers. RM 6.3.1.4.

I exported a subset of my database to GEDCOM. Created a new database and imported that .GED file. The option is still being offered in a checkbox for me.

[TomH]

I exported a subset of my database to GEDCOM. Created a new database and imported that .GED file. The option is still being offered in a checkbox for me.

You hit on it. If one selects a RootsMagic GEDCOM, the option is there. If it is a TMG GEDCOM, it is not. I wonder if that is true for all non-RM GEDCOMs. And why? I suspect that many migrants would find it desirable to have the same RIN in RootsMagic that they are familiar with in their original database. Renee?

[Alfred]

It has always been true of non RM GEDCOMs.

 

There was a workaround that worked for some programs where we changed the name of the source of the GEDCOM to RootsMagic, but that would only work if the creating program used the record numbers as the GEDCOM numbers.

[TomH]

It has always been true of non RM GEDCOMs.

 

There was a workaround that worked for some programs where we changed the name of the source of the GEDCOM to RootsMagic, but that would only work if the creating program used the record numbers as the GEDCOM numbers.

I was about to try that workaround, Alfred, but wonder if the identity of the GEDCOM source also invokes certain procedural differences to accommodate some differences of interpretation of the GEDCOM spec among different programs. In this case, TMG is the source. The INDI number in the GEDCOM corresponds with the invisible record number in TMG which also exports to REFN its visible number. So REFN can be made visible in RM and reliably appears after the INDI line in the GEDCOM and is the reliable way to relate the three. It's just that RootsMagic has the convenient record number search which is much faster than searching for a Reference Number so it would be easier to get an INDI value from the GEDCOM and find the matching record in RM.  

[Renee Zamora]

If we can't guarantee that the record numbers will be preserved then the option is not available. Since no program stores Record Numbers in the GEDCOM we have to strip it out of the cross reference. The only programs we can guarantee the preservation of the record numbers from a GEDCOM are made with RootsMagic, Family Origins and Personal Ancestral File (PAF). 

 

We are working REALLY hard on a direct import from TMG to RM so just be patient and this won't be an issue.

[TomH]

I would take exception to

Since no program stores Record Numbers in the GEDCOM we have to strip it out of the cross reference.

because I have observed that the INDI number in the TMG GEDCOM corresponds to the hidden record number in the appropriate TMG file. I don't see a reason why record numbers for a database imported from a TMG GEDCOM cannot be preserved.

GEDCOM will continue to be the method of transfer from a TMG user to another user of RootsMagic so I don't see that direct import eliminates the need for reliable, accurate import from TMG GEDCOM. I understand the priority from a marketing and revenue perspective.

[Renee Zamora]

I suspect development is looking at GEDCOM issues from TMG to RootsMagic too, since people need both methods.