TomH

Subscribe to the TMG-REFUGEES mail list http://archiver.rootsweb.ancestry.com/th/index/TMG-REFUGEES to hear what other prospective émigrés are discussing and partake therein. Members have also started a website to collect info on various alternatives to TMG; it's at https://sites.google.com/site/tmgrefugees/ and you can subscribe to become a contributor.

I ran into the same error doing the 9.04 update from the 9.03 program itself. Your alternative procedure overcame the problem.

RMπ 1.0.4 now processes TMG GEDCOM PLAC values into RootsMagic Place, Place Details and Place Detail Notes with some caveats. For details and download, visit RMπ (RMpi) GEDCOM Pre-Import Tweaker for RootsMagic

Some RM users wish for the ability to batch add a Reference Number to each person with the value of the current RIN. I wrote a SQLite query to do that and have used it on databases I have subsequently imported into my main database so that there was a reference back to the original. This is especially useful if there has been a book published from the original that made use of the record number. So I can understand that it may be desirable for the TMG reference number REF_ID to be exported both in INDI and in REFN, regardless of the destination database system. However, it may be desirable, as I have done, to prefix the number in the REFN with something that distinguishes it from other numbers, e.g., "TMG", which might then be readily searched and replaced by whatever the end user wants in some other database system.

Oh, I'm larnin' from you guys. You'd be welcome additions to the RootsMagic user community. I think there's a deep understanding of GEDCOM and database systems in the TMG user community, viz the number and quality of utilities and addons of longstanding, the high level of much of the discussions in this forum and on TMG-L.

Thank you, Michael and Jim for the explanations. I do understand the role of the GEDCOM INDI record number, what I mistook was what TMG exported to it; I understand now that it is REF_ID and not the invisible PER_NO. RootsMagic, and I suspect some other programs, have the option to "preserve record numbers" on importing into an empty database, except that option is unavailable when importing a TMG GEDCOM. In RootsMagic, the unique Record Number is more convenient and effective for display, for user navigation and for searching than the non-singular REFN. It can optionally be displayed after the person's name and there is an accelerator key combo to find a person by RN. REFN can be an alternative post-name display (as can FamilySearch ID) but because there can be multiple REFNs for a person, only the first REFN record created is so displayed. Hence, the suggestion to output the REF_ID value as the first REFN, thinking that it would be the more useful and familiar if the INDI value (TMG REF_ID) could not be preserved in RootsMagic as its record number. I have since experimented and found a way to trick RootsMagic into offering that option - the last SOUR in the HEADer must have the value "RootsMagic". So it may be that some value from TMG other than the REF_ID could well be more advantageous as the first REFN but that may vary from one user to another. Certainly, importing into an existing database precludes the preservation of record numbers, in which case, it is likely that most would prefer the TMG REF_ID as the first REFN. My RMπ utility 1.0.3 now includes the aforementioned trick. Running a TMG GEDCOM through it and importing the processed GEDCOM into a new RootsMagic database with the "Preserve record numbers" option selected results in the RootsMagic Record Number (RIN) matching the TMG REF_ID. >edited 3 Sep 2014 14:20 UTC

The GEDCOM INDI number exported from TMG corresponds with a number in the database table that I do not see in the TMG UI. The visible number has been exported as a REFN in the two projects I have looked at. The two numbers do not necessarily match. RootsMagic has the capability to "Preserve record numbers" offered as an option for GEDCOM from RootsMagic and perhaps others but not for GEDCOM from TMG, I.e., the GEDCOM 0 @I532@ INDI line would create a record in RootsMagic with the Record Number 532. A trick may be to change the GEDCOM HEAD info from TMG to RootsMagic in order to trick it into offering that option. The first of multiple REFN values for a person can be optionally displayed after their name in RootsMagic but it is not as convenient as the Record Number for searching. Make sure that the more useful REFN is written first. If the record numbers of TMG were highly visible and RootsMagic preserved record numbers on import from TMG, user convenience would be improved.

I have found these anomalies in assisting a TMG user migrate data to RootsMagic: TMG outputs the unlimited length Citation Detail field to +1 PAGE using CONC|CONT for overflow of the max linewidth setting. GEDCOM states {0:1} lines, i.e., no CONC|CONT. There does not seem to be a field within TMG to store the page value corresponding to WHERE_WITHIN_SOURCE that should go to PAGE value separate from the lengthy transcription text or TEXT_FROM_SOURCE that should go to +2 TEXT. RootsMagic accepts the PAGE CONC|CONT into its Page field up to some length beyond which it puts it all into its Research Notes field (+1 NOTE). Is there a way to enter data in TMG that does separate WHERE_WITHIN_SOURCE from TEXT_FROM_SOURCE into the correct tags, PAGE and TEXT respectively? TMG outputs a synthesis of its Surety values to +0 QUAY [0-3] which RootsMagic does not recognise either because it is on the wrong level or RM has no way to map a single digit to a 3 value quality indicator. GEDCOM specifies that it should be output to +1 QUAY, not the same level as n SOUR. Simply changing the line to "n NOTE {TMG QUAY 3}" for example, puts the note into the note of the fact for which the source is cited. That's really awkward given that it is the quality of the citation that is being described, and really confusing if there are multiple sources cited. TMG outputs source citations for Notes, unsupported by GEDCOM, by RootsMagic and by others, I'm sure. It would avoid loss of these citations with their transcriptions and analyses if TMG had an export option to "Move citations for Notes to citations for corresponding Facts" or words to that effect where "fact" means event and attribute in GEDCOM. ​Because of these GEDCOM errors, I am guessing that other software has similar problems with importing from TMG. Is there any prospect of these being corrected? My apology if my use of TMG terminology and understanding of how it works is flawed.

I found some previous discussion about the failure to export anything from embedded citations and a suggested alternative:

That's true. Embedded citations are just text and do not link to records in the citation table. I understand that the citation is not in a table but the master source it cites (#1 in this case) is in a source table. I don't understand why the phrases between the code tags are not part of the resulting parenthetical note in the narrative output but that is beside the point which is that the source description is retrieved from that table. I'm not surprised that there is no citation SOUR tag exported for an embedded citation but what does seem reasonable to expect is that the parenthetical citation as it appears in the narrative should also appear in the exported NOTE.

Embedded citations don't export. This is the Marriage Tag Memo: ceremony performed by Rev. D. B. Cooper.[CIT:]1:3;this is a citation detail;this is citation memo[:CIT] Now is the time for all good men to come to the aid of the party. This is the narrative: ...on 29 Sep 1863 at Brookfield, Linn County, Missouri; ceremony performed by Rev. D. B. Cooper. (Family data, Alexander/Keebler Family Bible, Holy Bible (New York: American Bible Society, 1854); original owned in 2000 by Lissa Soergel, (504 North Quaker Lane, Alexandria, Virginia 22304-1827). The Frank Alexander Family Bible passed from Frank to his daughter, Carrie (Alexander) Barns; to her nephew, Allen Long; to his cousin, Lissa Soergel (great-grandaughter of Frank Alexander).) Now is the time for all good men to come to the aid of the party.vi,vii The embedded citation can be seen between the blue blocks of text that came from the Memo. Here is the GEDCOM: 1 MARR 2 DATE 29 SEP 1863 2 PLAC Brookfield, Linn County, Missouri 2 NOTE ceremony performed by Rev. D. B. Cooper. Now is the time for all good me 3 CONC n to come to the aid of the party. 2 SOUR @S2@ 3 QUAY 2 2 SOUR @S12@ 3 PAGE Uncle Sam & Aunt Bell married Sept. 1863. 3 QUAY 2 Source #1 was cited; it's not listed as a source nor is it expanded by TMG to be exported in the NOTE. Suggests that users wishing to migrate should make sure that embedded citations are also normal citations.

John, have a look at these: http://www.pcworld.com/article/2455471/how-to-kill-unwanted-processes-and-applications-that-slow-down-windows.html http://www.top-windows-tutorials.com/windows-8-task-manager/

Not sure what you mean, Tom, but I don't think so. There are only one set of citations to a TMG tag. My error, especially given that RootsMagic's "shared events or facts" behave the same way. Forgive me - I am an utter novice with TMG and have no intention of becoming expert. Hmmmm... Tom, are you suggesting that Tom Giammo has implied a discontinuation of support for his "Witness TMG Program" I really should let TPG answer that but he developed it for his own purpose and is sharing it with us. I wouldn't. I think the purpose of this custom "Witness" event is to refer back to the Principals' event, where the source(s) would be fully cited. So I don't see a need to duplicate. I will reiterate the other reason and emphasize the convenience for both the author in editing such events within the database into a satisfying shape and for the reader in finding the cited evidence for a non-principal: That said, ...

I wouldn't. I think the purpose of this custom "Witness" event is to refer back to the Principals' event, where the source(s) would be fully cited. So I don't see a need to duplicate. Except that TMG allows unique sources for the witness tag and unique citations of sources common to the principal's events, does it not? Those may be written read differently from that of the principal. If reading a report about a person, one would prefer, I suspect, to have a footnote or endnote that is referenced from the sentence or phrase about the person's role in somebody's wedding and not have to look up the principal to find the evidence. That said, this discussion may prove to be just wishful thinking.

RootsMagic ignores it, at least under an EVEN. So NOTE is the only logical place that all software should recognise which is why I suggested it be duplicated there within sensitivity/privacy braces which RootsMagic and TMG both can act on (and therefore probably others) and, for at least RM (and possibly others), have the value on the EVEN line. That said, as long as the output begins: 1 EVEN 2 TYPE Witness: [role] in [eventtype] for [Prin1] and [Prin2] it is possible to batch revise the GEDCOM to 1 EVEN [role] in [eventtype] for [Prin1] and [Prin2] 2 TYPE *Witness for RM without affecting anything else in the GEDCOM. It's fiddly, but, if this is as far as Tom wants to go with the utility, it is usable.

I guess one should add Sources to that, also, although they might be the most complicated to implement, i.e., referencing an already existing source or creating a new master source. Another wrinkle is PLACE format, given that the TMG Export gives options for formatting places and what levels to include in the GEDCOM. Otherwise just accept that the same place may end up as two places in the destination database for the user to merge there. For RootsMagic, I prefer that the "Witness:" prefix should end up alone on the TYPE line, as: 1 EVEN [role] in [eventtype] for [Prin1] and [Prin2] 2 TYPE *Witness 2 DATE [date] 2 PLACE [place] 2 NOTE {[role] in [eventtype] for [Prin1] and [Prin2]} [Witness memo] ... Otherwise, a new RootsMagic fact type is created for each unique TYPE value. This way, only one "*Witness" type is created. The leading asterisk helps to flag it as a custom fact type and sorts it to the top of the list of fact types. RootsMagic accepts the value on the EVEN line as it does for other standard event and attribute tags but it is a custom GEDCOM extension. Repeating it in the sensitivity/privacy braces in the NOTE ahead of [Witness memo] assures that it will be imported to other software. A multiline regular expression search and replace on the GEDCOM modified by the current witnessTMG can modify it accordingly. Notepad++, among others, is capable of doing so. Without modification, witnessTMG should be useful to the pioneering emigre from TMG as it provides a means of identifying in the destination database those events for which the user needs to refer back to the TMG database to decide what should be done to it in the new system. For example, conversion of the event into some other type, copying notes, citations of imported and unimported sources... Undoubtedly, every migrant will need to do careful comparisons and probable editing in order to be satisfied that all which is needed has been transferred as well as is wanted. Thanks, Tom.

Jim, thanks for the clue to searching. I had looked at List of Citations but misinterpreted the Subject(s) of the report to be equivalent to RM's Select People. Michael, I see || in the export of Citation Memo to GEDCOM NOTE so it looks like it is only Citation Detail that filters out all but the first segment.

If CM1 is all that is exported, then one should use something other than || to delimit Transcription from Comments. I would suggest {} or %%. (the whole Citation Memo is exported c/w the delimiters || ) Interesting to me is that Jim's exploit of this TMG feature is something I have been beseeching for RootsMagic. That is, the ability to utilize source sentence templates internally for superior footnotes and for the drafting of a coexisting Free Form footnote for export to standard GEDCOM. Currently, you can have one but not the other. Its source templates do not export well to standard GEDCOM.

How do you search for Citations for which Citation Details contains a delimiter, i.e., CD1, CD2...?

Jim, I finally got the reason why I am seeing QUAY at the same level as SOUR. You have probably said why a few times about not checking SOUR. I now see that it is the option SOUR level in the Export Wizard which should be left unchecked. ("When selected, surety values (QUAY) are exported at the same level as the source citation from which they are referenced in order to accommodate certain importing programs.") I also see in Help "NOTE: If the citation detail is split, only CD1 is exported". Then, I think that a TMG user emigrating via GEDCOM to RootsMagic should edit Citations so that Citation Detail contains only the "where in the source" information and no || delimiters, moving all else to Citation Memo where the || delimiter might be used to separate Transcription from Comment. One might also enclose the transcription in sensitivity markers {same as RootsMagic's privacy markers} as that may facilitate moving the transcription to the correct field in RootsMagic. I believe this strategy would also be advisable to prepare for RootsMagic's future direct import because the migration is from two fields (Citation Detail and Memo) to three (Page, Research Notes and Comments).

Reviewing the GEDCOM again: 1 RESI 2 DATE 1892 2 PLAC , Chicago, Cook, Illinois, 2 SOUR @S18@ 3 PAGE p1637, 1892, 2 QUAY 2 Is TMG attempting to ascribe QUAY to the RESI or is it attempting to ascribe it to the citation, erroneously? Because, from the same database, I see: 2 NOTE or Slown, or Slowie 3 SOUR @S3@ 4 PAGE p273 4 QUAY 2 which correctly ascribes QUAY to the citation. I think there is one class of events or attributes or things for which TMG outputs the correct level of QUAY for their SOURs and another class for which it is off by 1.

Perfect.

Uhh, TMG sureties are more complicated than RM, for sure, which has a three-dimension Quality rating based on Elizabeth Shown Mills' advocacy but applying only to the citation itself, not to Prin1, Prin2, Date, Place, Memo... I cannot speak for other software. The only place that the GEDCOM standard shows QUAY being used is for a SOURCE_CITATION, at the same level as PAGE, so, yes, your example is what I would want to see in the GEDCOM. The QUAY tag can be readily replaced with NOTE and the value surrounded by something useful such as a label and privacy braces: 2 SOUR @S6@ 3 PAGE MS, Attala Co., Attalaville, p. 467, Sh 207 Ln 39 (Nat. Arch. Film #M653-577) 3 NOTE {TMG QUAY 2} The end-user can search for the "{TMG QUAY" string to find citations for which they may wish to edit the destination software's rating system, perhaps looking back at the TMG data to interpret. Alternatively, a direct read or a TMG utility could populate a note with something like "{TMG Surety vwxyz}" to facilitate the manual translation. I think I have given a rationale above for doing something with them as a convenience for the emigre but I agree that it is debatable. I think that makes sense. Just be sure to use one or few consistent values for TYPE as each different one becomes a new Fact Type in RootsMagic.

Thanks, Jim and Michael, for confirming the relationship of the two TMG Citation fields to the two GEDCOM fields. I wondered if the || separator had some effect on parsing the Citation Detail into the GEDCOM PAGE and TEXT tags, the latter being where the transcription should go but I suspect it just passes through literally to the PAGE field only, because 8 or 9 separators are allowed. Putting the transcript in the Citation Memo field along with the analysis and commentary causes both to end up in the NOTE field and in RootsMagic's Citation Comments from which the transcript needs to be parsed out and put into either TEXT in GEDCOM or Research Notes in RM. It has now been stated twice today in the RootsMagic forums that The RootsMagician is working on a direct import from TMG but there is no ETA. Whether direct or by GEDCOM, mapping from two fields in TMG to three in RM is not on and I think the same strategies should be used to prepare the TMG database for export. Move all but the key navigation reference from Citation Detail to the beginning of Citation Memo, bumping what was there down and separating them with the || separator or some other distinctive one, e.g., {} which can be suppressed in RootsMagic reports. These separators could be used with custom scripts operating either on the GEDCOM or on the SQLite database to move the stuff ahead of them to the correct place.

Hi John, I get an error message trying to open a TMG9 project with your utility, something to do with it not supporting project structure version 11 databases. Any prospects for it to be revised to support TMG9? It does, after a quick response from John, having to do with getting the appropriate compatibility.ini file from http://www.johncardinal.com/tmgutil/compatibility.htm Support doesn't get any better than that!