TMG-L Archives

Archiver > TMG > 2004-01 > 1073776193

From: Wade Oram <>
Subject: Re: [TMG] GEDCOM "locked" on import
Date: Sat, 10 Jan 2004 23:09:53 +0000
References: <001801c3d6f7$156347c0$6ac489d9@parkfarm><000201c3d712$0c8c2480$6401a8c0@MYRNICE>
In-Reply-To: <000201c3d712$0c8c2480$6401a8c0@MYRNICE>

In message <000201c3d712$0c8c2480$>, William M Roberts
<> writes
>Import it into PAF (which you can get for free) and then use GenBridge
>to move it to TMG.

Whilst GenBridge is obviously the way to go when given a data base from
a supported family tree program, I think that something is seriously
wrong when a third party program has to be used as an intermediate step
when importing a GEDCOM file - especially when, as John Liddle
suggested, simply removing one line will allow it to import correctly.

With direct GEDCOM to TMG, there is only on question of interpretation -
i.e. how the Wholly Genes developers have chosen to interpret the GEDCOM
standard. It the GEDCOM->Paf->TMG route is taken, then there are two
questions of interpretation by two different sets of people. I.e. How
the PAF developers choose to interpret the GEDCOM standard and how the
TMG developers choose to interpret the PAF database.

I think a good analogy would be primary vs. secondary sources. You would
always prefer a primary source to a secondary one because there is only
one interpretation process - your own as you transcribe the pertinent
facts into your family tree records. Similarly you should always prefer
the direct import mechanism where it exists rather than an indirect one.

As a result, I think that if, as suggested, the original import problem
was purely down to the 'DEST PAF' line present in the GEDCOM file header
record, then this should be addressed. However, my own tests(1) seem to
suggest that this alone is not the whole story.

I can think of no good reason for TMG to refuse to import a GEDCOM file
with such a header record. There is certainly nothing in the GEDCOM
standard itself to prohibit TMG from importing files with any particular
DEST destination(2).

For myself, if I ever encounter this problem, I shall certainly be
taking the 'delete the "DEST ????" line' route from the GEDCOM file
method discovered by John.

(1) I edited a small GEDCOM file that I already had (originally created
by TMG4 so that it the Source and destination family history system
records in the header both said PAF and proceeded to import this with no

(2) The GEDCOM 5.5 standard describes the HEADER record as containing a
"The name of the system expected to process a GEDCOM-compatible
transmission" it then goes on to say the for submissions to the Family
History Department (of the LDS) it must be 'ANSTFILE' for ancestral file
submissions and 'TempleReady' when submitting for temple ordinance
Wade Oram

This thread: