* From TMG into FH project by GEDCOM

[Rich Scats]

I am & have been a long time user of TMG and I do like FH6 and use it for new projects etc.
Currently I have a web site created by John Cardinal's Second Site which for the time being I can only use TMG to update it but hopefully this will change sometime in the future with a promised Gedcom version.
So for the time being I need to run TMG in parallel with FH6 so I keep both up todate.
I can export a Gedcom file for a family group of about a dozen individuals from TMG into FH but on a successful import the ID numbers change for the unmatched Individuals.
Is there anyway of retaining the TMG ID numbers during/after the import?
I have looked at Custom ID numbers but that looks messy and I need to continuity of ID numbers as I use Custodian 4 to store my one name study data.
Regards
Rich

[tatewise]

As far as I am aware Importing a Gedcom into FH should retain all Record Id numbers providing they are numeric and no greater than 2,147,483,647.

You might also trying using the direct TMG Project import as described in how_to:import_from_tmg|> Import from The Master Genealogist (TMG).

However, it sounds like you are doing more than an import, but subsequently performing a File > Merge/Compare Files and it may be that which is renumbering unmatched Individuals, perhaps because they conflict with existing Record Id.

Please describe exactly the process & commands you are using, and at what stage the Record Id change.

However, the Custom Id technique may be the best solution, because you are in full control of them.
You can easily copy all the existing Record Id to Custom Id using Tools > Work with Record Identifiers.
Then you can align any incorrect Custom Id with your Custodian Id.
Subsequently, make similar corrections manually for each new family you import/merge, just for unmatched Individuals.

[Rich Scats]

Mike you are correct in that I'm merging a Gedcom file into a project.
It's only after I use the merge button the ID numbers change apart from the two individuals that are matched.
apart from the pair of individuals who have a 4 figure IDs the others have 3 digits

I can look at the Gedcom file almost as a new project and the ID numbers are retained so can I merge a project into another project ?
by the way I have duplicated/copied my project so I can keep trying out different methods to be able to look at the end result.
rich

[tatewise]

OK, that confirms what I thought.

Because the Merge actually only uses the Gedcom file, merging a Project is the same as merging a Gedcom. However, it is good practice to create a new Project from that new Gedcom and run all the usual import validation checks and conversion Plugins to correct invalid data.

Unfortunately, any unmatched records from the Merge always get assigned new Record Id starting from the largest Record Id already assigned in the current Project.

There are solutions involving the use of Custom Id or Automated Record Id and Tools > Work with Record Identifiers.
e.g.
Before the Merge use Tools > Work with Record Identifiers and Copy existing record ids into the Automated Record Id field on the both the current Project and new Project/Gedcom.
After the Merge use Tools > Work with Record Identifiers and Generate new record ids by copying Automated Record Id values on the updated current Project.

If you wish, those temporary Automated Record Id values can be easily deleted via an Individual Query. However, if retained they may yield warnings in some cases, because that is a rarely used field, but they avoid the need to use Tools > Work with Record Identifiers before the Merge on the current Project next time (but it still must be used on the new Project/Gedcom).

Alternatively, if you are not using it for anything else, you can substitute the Custom Id in all the above operations.

If any of that does not make sense then please ask.

[Rich Scats]

Many thanks Mike
I'll certainly investigate & try out your suggestions
Regards
Rich

[Rich Scats]

That worked a treat Mike including with a single individual
Many thanks
you're a star
Regards
Rich

[tatewise]

I am glad that worked OK Rich.

Whenever you import a Gedcom remember to review the new database using the techniques listed in how_to:index#importing_to_family_historian|> Importing to Family Historian under "Use the following advice to repair common residual problems."

When Second Site supports Gedcom files perhaps you could start a new thread, so we can investigate the best method of exporting a suitable Gedcom from FH, that will probably involve the Export Gedcom File Plugin.

[Bob Adams]

I am also a long time user of TMG and Second Site. I'm considering migrating to another genealogy program since development of TMG has been discontinued. I've purchased Roots Magic and Legacy and done some evaluation of both. But I have decided to postpone any migration decision until the Gedcom version of Second Site (SS) is released. Once the new version of SS is released, I'll download and evaluate the trial version of FH before I make my migration decision.

As part of my pending migration, I have been using Clooz 3.5. With Clooz, you can import TMG into Clooz via Direct Read and export from Clooz to TMG via Gedcom. You can import FH into Clooz with a direct Read and export from Clooz to FH with direct write. The linking of RINs between TMG > Clooz > FH is automatic and may solve your probem.

Since I haven't downloaded FH yet, I haven't tried that process yet. But I have tested the process with Legacy usind Direct Read and Direct Write and that process is great. This will alow you to enter new information directly into Clooz and then export that new data to TMG and FH.

You can download a PDF file about exporting from Clooz to other programs at http://www.clooz.com/PDFs/ExportingFromClooz.pdf. You can also download that pdf from the "What Features Does Clooz 3.5 Have?" link on the Clooz website homepage.

You can download a free 14 day trial from the Clooz home page. If you try this, I hope you will share your experience.

I have no financal interest it Clooz, just a user of their program.

Regards,
Bob Adams

[tatewise]

Bob, thanks for that insight. However, there is a more direct route, because TMG Projects can be directly imported into FH. Whichever method is used there is likely to be some loss of certain details because database schema are inevitably incompatible. The more steps the greater the risk of loss.

Nevertheless, that is not Rich's problem. He can import into FH without problem, but he is only transferring one family group at a time that needs to be merged with the main Project FH database. It is that merge that upsets the Record Id, and if he transferred via Clooz a similar merge would be needed with similar consequences.

[Bob Adams]

Mike, I understand TMG data sets (projects) can be directly imported into FH. For the initial migration from TMG to FH that would surely be the approach to take. Admittedly, I have no direct experience with FH and my initial impression of the process could be entirely wrong. Based upon prior experience with other software, the following is my questimate of subsequent imports into FH.

Since Rich wants to run parallel systems, he would elect to enter new data into TMG and then import the new data into a new FH file since a direct import from TMG to FH is probably far better than a Gedcom from FH into TMG. At this point I get even fuzzier. I don't know if it would be best at this point to delete any "old" events from the new file and then merge or merge and then delete duplicated facts/events. In either event, it could be time consuming if the individuals involved had a large number of facts/events. Then he would use the solutions you provided to retain the existing TMG ID number.

On the other hand, he could enter the new data (documents) into Clooz. Once entered, he would activate the previously established link to the FH file. The FH Record for the individuals would appear on one half of the window, the Clooz data for that document on the other half. He could then elect to Directly Write some, all, or none of the data from Clooz directly to the appropriate FH records. The Clooz data can contain peiple, events, source, repository, and family. The existing FH ID numbers are retained solving the initial problem.

Then he could activate the previously established link to the appropriate TMG project to transfer the data for that record to the TMG project. Unfortunately the transfer cannot be directly written to TMG but must be done via Gedcom.

On the surface, update via Clooz appears to me to be the more direct and easier route. But I've been wrong before

BTW Mike, it does not take long lurking around FHUG to recognize and appreciate your contributions to the FH user community and to potential FH users.

Back to lurking. I seached for Clooz in FHUG this morning and found some other threads to review.

Regards,
Bob

[tatewise]

Unfortunately, the devil is in the detail.
I have dealt with transferring Project databases between many many genealogy products.
See the lists supported in my Export Gedcom File Plugin, and in how_to:index#importing_to_family_historian|> Importing to Family Historian.

A common theme is that none of them support the data structures of all the others, and the shared subset is comparatively small. So the question is what is the shared data structure subset common to TMG, Clooz, and FH?

The snag with the 'better' direct import from TMG to FH is that it has to be a whole Project (unless TMG allows a subset to be easily created as a temporary Project.) Trying to Merge a whole Project with just a few updates into a very similar Project on FH is fraught with difficulties. Check the how_to:index#importing_to_family_historian|> Importing to Family Historian for TMG and you will see several corrections may need to be made. These would have to be repeated on every whole Project import from TMG, otherwise the Merge would not synchronise correctly, and require a great deal of manual interations.

If TMG allows say a Family group to be chosen and create a temporary Project from them, then that simplifies things. That subset of data can be directly imported into FH and processed as I described earlier. Possibly as you say going via Clooz may solve the Record Id problem, but does any data get lost enroute?