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 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.