This is NOT SQLite! Rather, RMπ (RMpi) is a little application that tweaks a GEDCOM file you want imported into RootsMagic for potentially more complete data transfer. More development may come later but it could be useful now, especially to early emigres from The Master Genealogist 9.0.3 and earlier.

Perhaps equally importantly for exchanges between RootsMagic databases, it works around the serious issue of truncation at the 100th character of fact Descriptions that happens both for drag’n’drop and for GEDCOM import in RootsMagic 6.3.1.4 and earlier. Export does not truncate or, at least, not so early.

Main screen on opening. Once you have selected a GEDCOM file, the Tweak button is enabled…Click it.

Live log window displays tweaks as they happen.

Download

RM_pre-import 103.zip Download and extract all files to the folder of your choice. Click on “RM_pre-import.exe” to launch the program.

RM_pre-import 104.zip This version parses TMG Place values into RootsMagic Place, Place Details and Place Detail Notes but takes a major setback in speed.

Tweaks

For brevity, the RM_pre-import utility will be referred to as RMpi. RootsMagic behaviours described are those of v6.3.1.4. The Master Genealogist behaviours are those of v9.0.3.

• NEW in 1.0.4: TMG Place values parsed into RootsMagic Place, Place Details and Place Detail Notes.
• NEW in 1.0.3: Modifies HEADer block so that RootsMagic will offer the “Preserve record numbers” option on importing into a new database; line counter to show RMπ is working.
• NEW in 1.0.2: RMpi now modifies Witness tags generated by Thomas Giammo’s WitnessTMG utility to create one custom “*Witness” fact type in RootsMagic. Use these to refer back to your TMG database and decide whether to create a shared event in RootsMagic, edit the *Witness event or leave it as is.
• RootsMagic truncates GEDCOM event/attribute in-line values at the 100th char and does not recognise subsidiary CONC|CONT lines. TMG exports unlimited length Memo fields to certain GEDCOM event/attributes. RootsMagic itself does not limit the size of entries in its event Description fields and exports them fully. Its own drag’n’drop process uses its GEDCOM export/import processes in the background, resulting in truncation of long event descriptions. RMpi converts the excess to the EVENt NOTE which RootsMagic imports without constraint.
• RootsMagic does not expose Notes, Citations and Media for the primary name of a person, the first NAME exported for the INDIvidual. RMpi shifts their level up so that they become exposed as general Notes, Citations and Media in RM.
• RootsMagic does not import street addresses from the ADDR tag and a subsequent CONT tag, only from ADR1 and ADR2. In the absence of ADRn tags, RMpi adds them with the values from ADDR and the first subsequent CONT.
• RootsMagic ignores the UID tag from Ancestry.com which may have been uploaded from a RootsMagic GEDCOM as a _UID tag. RMpi changes the UID tag to _UID which can then enable RootsMagic ShareMerge to identify and merge identical persons.
• RootsMagic ignores the _APID tag from Ancestry.com which is key to finding a source in the Ancestry database. RMpi places the _APID value within privacy braces in the Master Source Comment or Citation Comment (GEDCOM NOTE tags) from which it can be manually retrieved or, perhaps, some future process on the RM export will regenerate the _APID lines from the NOTEs (maybe RMpe or RMpx 😉
• RootsMagic ignores the Ancestor Interest (ANCI) tag and, likewise, the Descendant Interest (DESI) tag. RMpi converts them into EVENts of corresponding TYPEs and the value (currently a reference to another line in the GEDCOM) is stored in privacy braces in the NOTE, e.g. “{@SUB1}”. One can then look up that reference in the original GEDCOM and use RootsMagic Search and Replace to replace it with the interested person’s name. A future enhancement of RMpi might fetch the name.
• RootsMagic supports a DATE for INDIvidual NAME tags, which is not consistent with GEDCOM specs, but allows Alternate Names to be dated similarly to events. There is talk of the use of a custom _DATE tag from other software to respect GEDCOM. RMpi converts _DATE to DATE so that RootsMagic will import it.
• RootsMagic ignores the citation quality tag QUAY under some conditions not fully understood. RMpi stores the QUAY value in privacy braces in the NOTE for the SOURce value unless the NOTE already contains “Surety”.
• RootsMagic treats a line 1 DEAT Y as simply a flag indicating that a person is deceased, not as an event, and ignores all subsidiary information. If there are subsidiary lines such as a NOTE, RMpi revises it to “1 DEAT”, without the “Y” so that RootsMagic imports the subsidiary values.
• TMG exports under some conditions a citation (SOUR) tag under a NOTE which RM does not recognise; such citations appear to duplicate those for the parent events. RMpi deletes the unrecognised citation block.

Tips

Matching ID numbers between source database and RootsMagic

Be sure to check the option “Preserve record numbers” in the RootsMagic GEDCOM Import dialog. This option appears if the trick introduced in v1.0.3 works and only if it is a new empty RootsMagic database. It has been tested with TMG v9.03 and results in the TMG Reference field REF_ID, which is exported to the GEDCOM INDI record number, traversing to the RootsMagic record number (RN or RIN). Then, after importing, under the RootsMagic Tools > File Options > General choose “Record number (RIN)” from the drop-down listbox labelled “Number to display after name”.

RootsMagic GEDCOM Import dialog, showing the option “Preserve record numbers” which should be checked; by default it is unchecked.

RootsMagic File Options, found under the Tools menu, set to display the Record number (RIN) after the person’s name in most screens and reports.

TMG Export Settings

Export Reference field as: Reference (REFN) if you want to have the Reference number preserved in a RootsMagic fact, immune to changes in its Record Number. RMpi 103 does result in RootsMagic offering the option of preserving the TMG Reference number as its Record Number, without this setting, but the RN will change if a person is transferred to a non-empty database.

Exclusion: all checked for maximum data transferred.

Maximum GEDCOM line length: not critical. RootsMagic 6.3.1.4 and below truncates some event/attribute values at 100 characters; RMpi converts the excess to Notes.

Uncheck “Break long values between words” to preclude word concatenation.

Places: Place Levels: These settings are required for RMpi 1.0.4 or for a special fork of RMpi so that it can properly slot the TMG place fields in RootsMagic Place List fields Place, Place Detail and Place Detail Note. The GEDCOM will have lines such as:

2 PLAC , -Erwin Parsonage, Erwin, Unicoi County, Tennessee, , , , ,

The TMG Detail “-Erwin Parsonage” will end up in Place Detail while City, County, State, Country will be sent to Place. The rest of the values will go to the Place Detail Note. This can only work if there are 9 commas in each PLAC, hence all Place Levels are checked along with “Commas When Missing” and we do not want leading and trailing commas to be trimmed. Undoubtedly there will be cleanup to do in RootsMagic. Here is an example of the result from RMpi104 of an import of the TMG Sample Project:

History

2014-08-31 1.0.0 Published
2014-08-31 1.0.1 Enclosed ANCI/DESI values in NOTEs in privacy braces, e.g.: “{@SUB1@}”, because RootsMagic otherwise ignored it.
2014-09-01 1.0.2 Modifies Witness tags generated by Thomas Giammo’s WitnessTMG utility to create one custom “*Witness” fact type in RootsMagic
2014-09-02 1.0.3 Modifies HEADer block so that RootsMagic will offer the “Preserve record numbers” option on importing into a new database; line counter added
2014-09-06 1.0.4 TMG Place values parsed into RootsMagic Place, Place Details and Place Detail Notes; Live Log revised to use codes for higher speed.

Issues

Platform

RMπ was developed on the free but dated JustBasic 1.01 (website). It is not the most robust development system – much time wasted when it was corrupted by something – but a procedural language such as GW-BASIC or QBasic seemed to be appropriate for GEDCOM manipulation. And I thought the learning curve would not be so steep. Perhaps I should have tried to do it in Visual C#, which is what I used for RMtrix but I am now very rusty with what I had learned then.

Speed

Prior to v1.0.4, RMπ processed some 2000 GEDCOM lines per second on a vanilla Windows 7 laptop. The same file on RMπ 1.0.4 drops to under 1700 lps but is one that does not invoke TMG Place parsing; a small one that does knocks the processing speed down to ca 1000 lps. Replacing the Live Log with a Log file may recover some speed. However, speed is not necessarily an issue if the process is used only once (i.e., the results are acceptable).

Live Log

Not only does the Live Log affect speed of operation, its copy to clipboard capacity is small. It would be beneficial to write instead to a file which can then be opened by a more capable text editor. Moreover, the same text editor can have the original GEDCOM open with which the log directly relates via the Line Number. And the RMπ output GEDCOM can also be opened and related to the original by references such as the INDI number.

TMG Place Parsing

This may not prove to be generally reliable due to the flexibility that TMG offers and the variety of ways that users may populate its Place fields. The parser relies on a specific export setting causing a certain number of commas to be embedded in the exported PLAC value. This is of no consequence for fields lower in the list than Country but any values with commas in them at or above Country will throw it off.