13 replies to this topic

[John James]

I am not getting the preserve record numbers checkbox when importing a gedcom, can anyone else confirm.

from help file
Check Preserve record numbers if importing a file that you passed along to a colleague or fellow researcher.

[kbens0n]

If the program of your "colleague or fellow researcher" doesn't support RootsMagic (or Family Origins) record numbers ...then you'll not have that option upon attempting to re-import.

[John James]

If the program of your "colleague or fellow researcher" doesn't support RootsMagic (or Family Origins) record numbers ...then you'll not have that option upon attempting to re-import.

I don't get it even when I try to import some of my own stuff, however I am running in togo mode so will try again when I get home.

[Alfred]

The database has to be completely empty before you can preserve record numbers when you import a GEDCOM file.

[Renee Zamora]

You're not going past the screen with the option are you?
File >Import> Gedcom> I know where the file is> Select Gedcom - open>the next screen GEDCOM Import has the "preserve record numbers right near the bottom.

[John James]

The database has to be completely empty before you can preserve record numbers when you import a GEDCOM file.

Thanks, i got this working, if I select new database as Alfred said rather than combine the checkbox appears

[Romer]

This functionality makes some sense, as you could otherwise already have people in the database with the same record numbers as those you're trying to combine. In a new database, it's obviously not a possibility.

[John James]

This functionality makes some sense, as you could otherwise already have people in the database with the same record numbers as those you're trying to combine. In a new database, it's obviously not a possibility.

FYI, it also appears that it needs to recognise the RM header information in the gedcom.

[TomH]

Preserve Record Number is only logical if the database is being passed along through different systems and is not to be imported into another database. The Record Number is just the number of a row in a table. All new databases start at 1 and increment so there will be almost certainly a collision of record numbers.

For exchanging a database with others and importing back into a database wiith overlapping persons, the RootsMagic special feature of a unique ID for each person included in the export and preserved through all external processing and re-imported enables the RM ShareMerge function to combine identical persons. Record Number is irrelevant.

[kbens0n]

For exchanging a database with others and importing back into a database wiith overlapping persons, the RootsMagic special feature of a unique ID for each person included in the export and preserved through all external processing and re-imported enables the RM ShareMerge function to combine identical persons. Record Number is irrelevant.

Sorry, but it's seems like a wrongful leap to take in your mind, that Record Number is irrelevant ...especially in the context you just mention (exchanging a database with others). Preserving the Record Numbers allows for both parties to most easily find and refer to the same individuals in discussions or considerations.

[TomH]

Sorry, but it's seems like a wrongful leap to take in your mind, that Record Number is irrelevant ...especially in the context you just mention (exchanging a database with others). Preserving the Record Numbers allows for both parties to most easily find and refer to the same individuals in discussions or considerations.

Perhaps my description was not clear enough or precise. Preserving record numbers can only work if the exchange is restricted to an import into an empty database. Importing into a non-empty database, if it were allowed, would result in a collision of imported record numbers with pre-existing record numbers. Because a record number is a row number of a table, the imported persons must be assigned a new row and record number. That's what makes the record number unreliable, if not irrelevant, and that is why Preserve Record nUmber is only permitted on importing into a new, empty database.

With the UUID, two persons in the same database having matching UUIDs and necessarily different record numbers can be merged, using ShareMerge, and one of the two Record Numbers will be preserved.

For reliable exchange among different parties, assigning a unique Reference Number fact to each individual can serve the purpose of ensuring that all parties can find the same person in their respective databases, regardless of Record Number, which will most likely be different in each database unless they have a common Master database from which they take copies.

[KenCRoy]

FYI, it also appears that it needs to recognise the RM header information in the gedcom.

I don't think this is necessarily true, since I recall importing a PAF gedcom into an empty database and was able to preserve record numbers.

Ken

[TomH]

For reliable exchange among different parties, assigning a unique Reference Number fact to each individual can serve the purpose of ensuring that all parties can find the same person in their respective databases, regardless of Record Number, which will most likely be different in each database unless they have a common Master database from which they take copies.

I wonder if this does not suggest that a useful enhancement could be a user-selectable option on import of assigning the source file's record numbers for individuals to Reference Number facts for these individuals in the destination database. Ideally, there would also be a user-definable text prefix so that the resulting REFN would be the concatenation of prefix + recno. The assigning of a common source to all persons imported from a GEDCOM is already supported so the use of REFN in this respect seems like a logical and useful extension.

[Renee Zamora]

I wonder if this does not suggest that a useful enhancement could be a user-selectable option on import of assigning the source file's record numbers for individuals to Reference Number facts for these individuals in the destination database. Ideally, there would also be a user-definable text prefix so that the resulting REFN would be the concatenation of prefix + recno. The assigning of a common source to all persons imported from a GEDCOM is already supported so the use of REFN in this respect seems like a logical and useful extension.

Confirming enhancement request is in our tracking system.