* Copy Existing Reference Numbers in Gedcom File

[tatewise]

In Plugins planned/in progress (19399) it mentions a new Copy Existing Reference Numbers in Gedcom File plugin.

That is a neat idea but it seems to assume that every type of record can have a REFN or RIN tag and many cannot.
Very few allow a RIN tag and some don't allow a REFN tag. So the only reliable option is the _OLDREF UDF.
I'm not sure what happens when a GEDCOM is imported with invalid RIN or REFN tags. Maybe they become UDF.

[KFN]

Tatewise said:

That is a neat idea but it seems to assume that every type of record can have a REFN or RIN tag and many cannot.

Unless I misunderstand this statement, all GEDCOM v5.5.1 record types (FAM, INDI, MEDIA, NOTE, SOURCE, REPO) (not Submitter) allow the inclusion of both a REFN and RIN tag. If preserving an XREF is important when importing a GEDCOM from another application, then creating a RIN may be the answer, although GEDCOM only allows 1 RIN per record instance, where as you are allowed multiple REFN tags with a REFN.TYPE used to distinguish the various ones recorded.

[tatewise]

You are absolutely correct, I overlooked checking the GEDCOM 5.5.1 specification.
Unfortunately, FH has not implemented RIN for most of the records.
At least, it is not available on the All tab. I'm not sure what would happen if a GEDCOM has RIN for those records.

I will experiment with a GEDCOM that has all record types tomorrow.

Maybe the lack of RIN should be reported to CP?

[tatewise]

After running the plugin, the results are not as much of a problem as I anticipated, but there are a couple of wrinkles.

Custom ID option
Some products (e.g. Legacy) allow non-standard 2 REFN tags to be applied subsidiary to facts.
The plugin baulks at those and inhibits the 1 REFN tags used by the Custom ID option, even though they would be valid.

The plugin also baulks if 1 REFN Custom ID tags exist, even though multiple instances of 1 REFN are allowed.

Place (_PLAC), Submitter (SUBM) & Submission (SUBN) records import with * REFN UDF because Custom ID are not allowed.
However, this is unlikely to be a significant problem.

Automated ID option
Place (_PLAC) records import with * RIN UDF because Automated ID are not allowed.
However, this is unlikely to be a significant problem.

All other records import the 1 RIN Automated ID perfectly, even though there is no All tab option for that in most record types.
A 'feature' of Automated ID is that their values cannot be edited within FH.