TMG™ Import/Export ©MJH

Modified August 1, 2020 2:11 pm
This site works better with Javascript enabled.
Michael J. Hannah, Los Ranchos, NM.

Assuming you are using the final Version 9.5, you must “Import” TMG Version 4.x or earlier files, which have a file extension of .TMG, or Version 4.x or earlier backup files, which have a file extension of .SQZ. The program has considerable significant changes since Version 4 so you should expect to need to do a lot of manual changes and cleanup after importing such an early version.

For Version 5.x and all later versions of TMG you must “Restore” the TMG backup files, which have a file extension of .SQZ. Restoring backups of versions 5 or 6 will see significant changes, especially in the paths stored in the new Preferences / Current Project Options / Advanced. When restoring versions 5, 6, or 7 backups many of your old Preferences / Program Options will not transfer. You will completely lose the following three settings, which must be manually redefined:

• Custom style settings from the old Preferences / Program Options / Custom Styles tab
Manually enter the old styles in the new Preferences / Program Options / Custom Styles tab

• Text macro settings
Manually enter the old styles in the new Tools / Text Macros / Text Macros screen

• Tools / External Utilities settings
These advanced settings can be copied from your old app.ini file to the new app.ini file.

Most of your setting will automatically be retained from a version 7 backup, and nearly all from version 8 and 9 backups. But it is always a good idea to examine whether the transferred settings are still appropriate, such as paths to files used by TMG especially those for external exhibits. I highly recommend reviewing Terry Reigel’s Tips on “Moving Data to a New Computer or Version” after doing a restore:

Sources and source types are specific to an individual dataset within a project. Only those sources and source types defined in the dataset of the current focus person will be available for export in those Tools windows. Likewise, importing will only occur into the dataset of the current focus person.2 Source types are exported to an .XST file and the export includes only the selected source types and the source elements used by those source types. Sources are exported to an .XSO file and the export also includes all source types and source elements used by the sources being exported. Due to a remaining bug, ensure that any named custom Source Elements in the dataset being exported will not conflict with same-named elements which are in a different Source Group in the importing dataset. All repositories linked to any exported sources are also included if you select the option to do so, and then all places used by those repositories will also be included. Thus, usually you will export and then import just the sources desired, since almost anything else needed by those sources will come “for free”. Tasks linked to either the sources or repositories are not included in the export and therefore will not be part of the import.

You can only select specific sources or source types when exporting, not when importing, so be selective in the export. If you only wish to import selected ones from a larger number already in an existing export file, it takes multiple steps to create a more limited file. I prefer to first create a New project with only one dataset which has no sources, and delete3 all existing Source Types but the one that is default and rename that one something identifiable. Now import the full export file of Sources or Source Types. You could add a unique prefix to the imports either at this time, or as part of the subsequent import, if you wish their names to be unique. Now export from this temporary project only the limited number that you “really” want to import. In your “real” project now import that limited file.

The prefix specified for a Source Types import will automatically have a dash ‘-’ appended between the prefix and Source Type name. There is no option to avoid this dash when you explicitly import Source Types. The prefix specified for a Sources import will not have an automatic dash, and their linked Source Types will also have this Sources prefix4 without an automatic dash. You might want to end your supplied prefix for Sources, and thus their linked Source Types, with a dash for consistency. If Sources are imported with a prefix, the imported Repositories for those Sources will also be given that prefix. Whether as part of a Source Types import or a Sources import with linked Source Types, the imported Source Elements needed for those Source Types will not have the prefix.

WARNING: Incrementing for importing Sources or Source Types differs from incrementing Tag Types.

• the last character of the importing item’s abbreviation is a digit (regardless of how short or long the abbreviation), and

• that importing abbreviation would be identical to an existing abbreviation, and

then a digit is not appended to that abbreviation with a trailing digit. The existing trailing digit, which was part of the importing abbreviation, is incremented (e.g. “Source vol-2” becomes “Source vol-3”, or “Source 1923” becomes “Source 1924”). If the resulting abbreviation exists, the number continues to be incremented until it is unique (e.g. “Source vol-4”, or “Source 1925”). Further, if you are importing Sources, and some Source Types used by these sources will automatically be imported, whatever you choose at the options for prefix and incrementing (with the same trailing number issue) will also apply to the importing Source Types, without any opportunity to make them different. As noted above, any imported Source Element’s name will not be prepended with any specified prefix, but an element name will be incremented if there is an existing Source Element with that identical name in a different Source Group. Because of this increment issue, and since many of my sources and source types have trailing digits, I try to avoid importing a Source or Source Type which is already in the project/dataset, unless I intend to use the “overwrite” or “ignore” options.

Tag types are specific to an individual dataset within a project. A dataset currently marked as active can be selected to export tag types from that dataset in that Tools window. Similar to sources and source types, importing will only occur into the dataset of the current focus person.

Tag types are exported to an .XTT type file. Individual tag types can be selected as part of export, but all tag types in the file are imported without selection being possible. I would probably keep a full set in a single file, then import into a blank project/dataset, then temporarily selectively export just the ones I wanted to a temporary file, and now import only those. Similar to creating a smaller import file for Sources or Source Types above, this takes extra steps, but it would work.

If the importing and current tag type are identical, you will not import that tag type even if you specified a prefix in an attempt to make it different. The test for being identical is made before the prefix is added. Similar to importing Sources mentioned above, the prefix is added without an automatic trailing dash. I usually ensure that the prefix ends in a dash to make the imported tag type stand out in the list.

If you do not add a prefix, and choose to import and not overwrite even if the tag type is different but the name already exists, the imported name will automatically be given an incrementing suffix digit.

WARNING: Incrementing for importing Tag Types differs from incrementing Sources and Source Types.

• the last character of the importing item’s Label is a digit (regardless of how short or long the Label), and

then the digit is always appended to that Label. The existing trailing digit, which was part of the importing abbreviation, remains immediately in front of the new digit (e.g. Label2 becomes Label21). The existing trailing digit, which was part of the importing Label, is unchanged. If the resulting Label exists, the number being appended continues to be incremented until it is unique (e.g. if starting with an import of Label2 and Label21 exists the import tries Label22 not Label211).

WARNING: A Name tag type can be set to use a specific default Name Style in its Tag Type Definition. Likewise most other tag types can be set to use a specific default Place Style in its Tag Type Defintion. Unfortunately the import may cause the tag type to be linked to an unintended style. It appears6 that the style is stored upon export of that tag type as the nth style in the list of Styles. If the sequence of styles in the exporting dataset and the importing dataset are not identical, the tag type will be linked to a different style in the imported dataset than it was in the exported dataset. Unfortunately this makes exporting and importing tag types which use custom Styles very dangerous. All imported tag type definitions should be carefully checked to be sure they are set to the intended default style.

To export a portion of a project as a new TMG project, the most common way is to use the Secondary Output on either a filtered List of People or a filtered List of Events report. However, if a new Project is created based on the report filter, the resulting project will have its preferences and options set the same as those in a New and empty project. The preferences and options from the project where the report is being run will not be used. Normally to cause that exported new project portion to have custom preferences and options it is necessary either to manually create them, or to merge this new project portion into a project/dataset which already contains these preferences and options. A better alternative is to first create a new dataset within the existing customized project. One can create a new project which will automatically copy many customizations but only selected people, events, sources and repositories by using a filtered report defining the project portion. Alternatively one can create a new dataset within the customized project. This can either be done by using a filtered report defining the project portion which will automatically retain most customizations, or by adding a new empty dataset which will allow selecting which customizations are copied. Either will retain customizations associated with the information which is copied, e.g. tags, sources, etc. Once the new dataset is created, copy the entire project with both datasets. In the original customized project delete the new dataset. In the copied new project delete the original dataset thus providing a new project with the selected customizations.

As of Version 5, TMG always imports/merges one file/project into another, leaving the sending file unaltered. It is usually prudent to make a copy/backup of the receiving file/project first so that you can recover it prior to the merge if necessary. Due to a remaining bug, ensure that if there are any identically named custom Source Elements in the two projects that those same-named elements are in the same Source Group.

To ensure the existence of your program and project level customizations after the merge, make the receiving file the one that has all your desired customizations. Importing data will not create a dataset with customizations, it will use the settings for a New Project. Instead I always Import external data into a new separate dataset of a Project which has an empty (of “real” people) dataset with all my customizations, then merge that imported dataset into that prepared empty customized dataset. Of course you could just create a New project, then Export and Import selected Sources and Source Types, and Tag Types as described above.

There are two ways I use to create (export) a new Project but with a (nearly) empty dataset with all my customizations. The differences in these two ways is in what customizations are retained in the empty dataset. For me the primary difference is whether I want to retain the sources and repositories.

You can create a new dataset similar to the description below when creating a new project by using a filtered List of People report which creates a dataset. While this does retain some more customizations than when creating a new project (such as retaining tag type colors), it does not retain all sources and repositories. Thus if I want to retain them, I add a new empty dataset.

• “Add” a new empty dataset (not a new Project) using the Dataset Manager to an existing project which has your customizations. It provides options to select which of various features will be copied from the currently selected existing dataset. I generally choose to retain all of these as I find I use the same sources, places, etc. for multiple projects and I prefer having them already entered so all I have to do is cite them. Max length for a dataset name is 100 characters. When a dataset is created it usually has a “Data Source” field automatically created, usually a filename, but this max 253 character field can be edited after creation.

• Close the project within TMG and then use TMG to copy the entire project with its new empty dataset into a new project

• Delete all datasets in the new project except the new empty one, and renumber the empty dataset to ‘1’

• Either begin adding data to the empty dataset in the new Project, or Import then merge in data

Assuming you selected all the options, then all the custom tag types, as well as modifications to standard tag types are retained. All custom source types and elements, as well as all sources and repositories are also retained. All styles are retained. If you create the new project in a different base folder, the Accent definition files are not copied. You will need to copy the “*.acc” files from the old base project folder, and then load the one you want and apply it. Remember that custom flags are dataset dependent so that any accents based on flags for a differently numbered dataset may need adjusting. Customizations to the Add Person screen are not copied, you will need to re-apply these. All Preferences are retained.

• Open your Project, and either create a temporary new person with only a Name Tag and no Source Citations, or identify a set of people to be copied when making the new Project.

• Run a List of People report filtered for only that one person or set of people, and set the Secondary Output in Options to create a new Project.

• Either begin adding data to the new project, or merge in data from an imported dataset

None of the “Preferences / Current Project Options” are retained. They are all set to system defaults so you may wish to adjust them. But the “Preferences / Program Options” are all retained. The custom flags are retained, but their order may not be. The Add Person setup is retained. All custom source types and elements are retained, but only the sources/repositories cited to the copied people and events. One could then export any desired remaining sources from the original project and then import those sources into the new project. The styles are retained, but no places except those associated with any copied events. All the custom tag types, as well as modifications to standard tag types are retained, as well as any events associated with the copied people, but tag type colors are not retained.

Generally I want to not only keep all my customizations, but also many of my pseudo people, usually at least the Census, Location, Source, Repository, and Burial/Cemetery people. However, creating such a project copy is now more difficult since copying these “people” will also copy the tags linked to both these “people” and now missing “real” people. It can be done, but involves considerable clean up.

First I back up and then create a new dataset in an existing project which has all my customizations using a List of People report filtered for all the desired pseudo people based on a filter using the PSEUDO flag. This retains all the customizations and their original ID numbers. Retaining the ID numbers are of value to me since I link directly to Source people’s ID numbers in Source records. Next I copy the project. Now in the original project I either delete the pseudo dataset and do Optimize/VFI/Optimize, or just restore the backup of the project prior to creating the pseudo dataset.

Next in the pseudo project I delete all datasets other than the one with the pseudo people, renumber that dataset to ‘1’, and do Optimize/VFI/Optimize. I now need to remove any tags which make no sense without the “real” people, e.g. Census data tags in Census people, Burial tags in Cemetery people, etc. In some cases I may simply want to delete the pseudo person, such as a Source or Repository person which only relates to the original project. Since this clean up usually takes multiple sessions, I use a filtered List of People report to set my custom Edited Flag to ‘N’ for all pseudo people. I will then change it to ‘Y’ when I have reviewed and finished deleting undesired tags for a person, or just delete that person. I then will want to delete any Sources or Repositories which only relate to the original project. I may need to make separate copies of any external exhibits associated with what remains, such as maps for Location people.

Now I can start with this cleaned and near-empty project. I can add people or merge in a dataset or project which has “real” people. If I want to keep the ID numbers of the pseudo people I need to merge into this near-empty project/dataset. If instead I were to merge this near-empty project/dataset into another, all these pseudo people ID numbers will be changed as described for merging People below. I can always add or renumber people to unused numbers left as gaps around these pseudo people as described in the Style chapter.

Need to test and document more fully importing people using the “Add Multiple People” feature introduced in Version 8. Especially need to test what is required when importing a CSV spreadsheet of people. I have used this new feature to add new families but not via CSV, although it looks quite promising. TMG Help states:

“An Open dialog will let you select the CSV file to be used for the import. You can assign each CSV file column to a corresponding column on the Add Multiple People or Add Family screen by selecting the column on the left, selecting the CSV column on the right, and then, clicking the [< Assign] button. The Import will load the Multiple People spreadsheet. You may then edit the spreadsheet before clicking OK.”

This suggests that the order (and number?) of columns in the CSV file do not have to match the columns on the Add screen. Presumably the Add screen columns are affected by that screen’s current Setup, but I want to test this for myself and document it here.

See Terry’s Tips for an excellent tutorial on merging datasets.11 These notes focus on merging datasets using the Data Set Manager, and the impact of such merging on any customization done in either dataset, but have drawn heavily on his web pages. [Most of these features were last tested in Version 7.04. In August 2015 I discovered that at least one of the behaviors of merging custom features described below changed dramatically as of Version 8. Therefore, I need to revisit and test all of the behaviors below in the final Version.]

TMG Data Set Manager will copy any custom tag types from the sending dataset only when there is no tag type of the same name in the receiving dataset. Separate local customization of individual tags will be retained. If the receiving dataset has a tag type of the same name, the global customization to that tag type in the sending dataset is lost. (TMG has significant problems if the two identically named tag types are in different tag groups.)12 Where identical tag type names exist in both datasets but their global definitions are different, yet you also wish to retain the sending definitions, special actions must be taken for these tag types within the sending dataset before doing the merge.

When you know you have identical tag type names with different definitions and want to retain both, remove the name duplication before doing the merge. If the sending dataset tag type is a custom tag type, one could simply rename that tag type to a unique name. Open the Master Tag Type List, select and edit the duplicate tag type, and change the name in the Label field on the General tab. (Alternatively, especially for standard tag types, one could use the TMG Master Tag Type List to first make a copy of each of the potentially conflicting tag types used in the sending dataset to a new unique tag type name and then use something like the TMG Utility to change all tags of the conflicting tag types to these new unique types prior to the merge.)

TMG will copy any custom source types from the sending dataset when there is no source type of the same name in the receiving dataset. If the receiving dataset has a source type of the same name but different output templates, a number will be appended to the name of the type copied from the sending dataset to distinguish it from the duplicate one in the receiving dataset.

If the receiving dataset has a source element of the same name but in a different source element group, when merged a number will be appended to the name of the element copied from the sending dataset to distinguish it from the duplicate one in the receiving dataset.13

All sources of both datasets appear in the receiving dataset as cited, and the source numbers of the sending dataset will start one higher than the highest in use in the receiving dataset. If they are actually the same source, they will need to be merged individually.

All repositories of both datasets appear in the receiving dataset as linked, and the repository numbers of the sending dataset will start one higher than the highest in use in the receiving dataset. If they are actually the same repository, they will need to be merged individually.

If the receiving dataset has a style of the same name, the definition of that style in the sending dataset is lost. Any uses of duplicated style names will have to be individually resolved. (One could first copy all potentially conflicting styles used in the sending dataset to new unique style names and then use the TMG Utility to change all names and places of the conflicting styles to these new unique styles prior to the merge. If two styles are named differently but are actually identical, using TMG Utility after the dataset merge to optimize styles will merge these styles.) TMG will copy and use any custom styles from the sending dataset when there is no style of the same name in the receiving dataset.

The following paragraph describes the the effect on flags of merging people as of Version 7.04, but this has changed since then. If the receiving dataset has a flag of the same name, the definition of the values of the flag will not be copied from the sending dataset. The definitions and possible values in the receiving dataset will be retained. However, each merged person from the sending dataset will retain their flag value even if that value is not defined in the receiving dataset. Manually adding the missing values from the sending dataset after the merge to the definition of the receiving flag will not affect current settings of this flag. Duplicate named flags with differing definitions will have be individually resolved before the merge. The simplest method is to rename the duplicate flag in the sending dataset to something unique.14 When there is no flag of the same name in the receiving dataset TMG will copy any custom flags and their definitions from the sending dataset. People in the receiving dataset that did not previously have that flag will be set to the default value of the flag. The people in the sending dataset will retain their flag values.

As of Version 8 and continuing through the final Version 9.05, the effect on flags of merging people has changed in one significant instance. If the receiving dataset has a flag of the same name the behavior is unchanged from Version 7.04. However, when there is no flag of the same name in the receiving dataset the behavior has changed in one important way. TMG will still copy any non-existent custom flags and their definitions from the sending dataset. But all people in the receiving dataset now will be set to the default value of the automatically created flag including the people from the sending dataset. The people in the sending dataset will retain their flag values since that dataset is unchanged, but will lose their values in the receiving dataset.15 Now the simplest method to retain the values from the sending dataset is to first create a flag of the same name in the receiving dataset. (While not necessary, it would make sense to create this new same-named flag with the same definitions. As was also true in Version 7.04, each merged person from the sending dataset will retain their flag value even if that value is not defined for the existing flag in the receiving dataset.) First creating a same-named flag is also required to retain values from duplicate named flags with differing definitions needing to be resolved before the merge. Now the simplest method is both to rename the duplicate flag in the sending dataset to something unique, and create that same new unique named flag in the receiving dataset prior to the merge.

If the receiving dataset has an identical place as one in the sending dataset, duplicate entries will show in the resulting Master Place List until the project is Optimized via File >> Maintenance.

All tasks of both datasets appear in the receiving dataset as linked, and the task numbers of the sending dataset will start one higher than the highest in use in the receiving dataset. If they are actually the same task, they will need to be merged individually. If the task was linked to something not merged (e.g. a particular event tag or person) the task will exist and show as not yet assigned.

All exhibits of both datasets appear in the receiving dataset as linked, and the exhibit numbers of the sending dataset will start one higher than the highest in use in the receiving dataset. If they are actually the same exhibit, the duplication will need to be addressed individually. If they are external exhibits, change the links to exhibit two to now link to exhibit one and delete exhibit two. If they are internal exhibits they will be duplicates anyway, so decide whether you need both and possibly just delete one.

The people in the sending dataset are added to the receiving dataset. If they are actually the same person, they will need to be merged individually. The ID numbers of the people in the sending dataset will retain their ID order but begin at one number higher than the highest ID number in the receiving dataset, i.e. gaps in the ID numbers in the receiving dataset will not be used.

Some actions that will help merging are easier to do in advance while the two datasets are separate.

1. Create an identically named custom flag16 in each data set which will be used to identify the original dataset of the person and indicate whether that person has been reviewed. For example the flag could have three more values than the total number of data sets to be merged: if you are merging two data sets, then create flag values of 1, 2, M (merged), C (cleaned), and Q (questions to review later). When you create this flag have its default value be 1 for data set 1, and 2 for data set 2, etc. so everyone in each dataset will have the flag set to a value that indicates the original dataset.

2. Change the names of any identically named flags which have differing meanings in datasets to avoid duplication and confusion over differing meanings of the same flag or flag value.

3. Change the names of any identically named but differing Name and Place styles in one dataset to avoid duplication and loss of customization.

4. Change the names of any identically named but differing tag types in one dataset to avoid duplication and loss of customization. Be especially alert to differently modified standard tag types.

Because of the possible duplications or lost customizations mentioned above, some post processing is almost always required. Doing certain actions before others can lessen the amount of work. If there are sources in the import, I prefer to first add/fix all repositories, then fix the sources, then correct the master place list, and finally fix the citation data, surety and the tags. Some recommend fixing the master place list first, but I like to be sure I am retaining any source specific place names. The following sequence seems most efficient to me.

1. Add any new flag values to the definitions of a flag that will result from merging other flags. Might use the List of People report Secondary Output option to set the merged flag based on the old flag(s). Identify all possible flag values for each flag in each dataset, and set the values in the receiving dataset to the combined list.17

2. For the custom flag mentioned above that identifies the original dataset number you can set up an Accent scheme with distinct colours for all the values of this flag. Then the Expanded Picklist sorted by surname will show bi-colour pairs that are potential merge candidates, and the accenting will be in the parents and spouse columns as well.

3. Resolve any differing Place and Name Styles. Note above the suggestion to change identically named styles in one of the datasets before the merge to avoid loss of a differing style definition.

4. Resolve where source types exist in both datasets but their definitions are different resulting in a new Source Type in the list of Source Types that now has a trailing number. Run a List of Sources report filtered for “Source Type is”, and the filter has a dropdown list of all defined Source Types so you can find those with trailing numbers. (If there are no qualifying sources it will say so when you print the report and leave you in the report definition screen to edit the filter to check the next Source Type.) Now merge any duplicate source types. Running the above report first will tell you whether the type being deleted is actually used, and if it is will list the sources that will now need to be checked to conform to the elements and sentences of the new type.

5. Resolve identically named source data elements that exist in different source groups. Review the list of Source Elements, and note those that now have a trailing number (of course ignoring the elements CD, CM, M, Memo, Repository Memo, and RM that have trailing numbers 1-9). Identify the Source Types that use these elements and resolve the issue. At the moment the only way I can think of finding where these elements are used is a visual review of all the source type definitions.

7. Before merging sources, ensure that they are truly duplicate, e.g. they may be linked to different repositories and you may wish to keep them as separate sources. Merge duplicate sources one by one using the Merge feature on the Master Source List, and each time you merge two sources remove the duplicate repository references that will exist in the merged source, making sure one (and only one) repository remains marked primary.

8. For Places, make what should be duplicates become duplicates (see below), then File > Maintenance > Optimize to merge these duplicate places in the MPL. Note that locations from the sending dataset may not have my special F2 sort code in the Addressee field, and these will need to be added to make them become duplicates.

9. Resolve where tag types exist in both datasets but their definitions are different resulting in the loss of the tag type definition in the sending dataset. One might use the TMG Utility to “Export Sentences” to a text file for each dataset and compare the two files. One could also do a visual review and comparison one by one of all the tag type definitions in the two datasets. Since you can have two instantiations of TMG open at the same time, one on each dataset, this can be done on screen.

10. You cannot merge exhibits. If they are external, change the link; if internal, decide if you need both.

11. Merge people and their tags. See the separate discussion below on this topic for more details.

12. Add any newly required location pseudo people. This might be facilitated by comparing the two reports: List of Places to show the Master Place List, and List of People filtered for the PSEUDO flag set to ‘L’.

13. Add any newly required repository pseudo people. This might be facilitated by comparing the two reports: List of Repositories to show the Master Repository List, and List of People filtered for the PSEUDO flag set to ‘R’.

14. Add any newly required source and/or census pseudo people. This might be facilitated by comparing the two reports: List of Sources18 to show the Master Source List, and List of People filtered for the PSEUDO flag set to ‘C’ for census and ‘S’ for sources.

Other dataset merging issues [Note to self: need to combine these thoughts in other sections]

Import each GEDCOM (see further discussion on this). Check option19 for PRESUME MARRIAGE and uncheck the one for creating a married name. Go into the new file and create a source telling where the GEDCOM file came from. Then use Utilities/Advanced/Cite and cite the source globally. Alternatively, manually create a single note of the data provided in the GEDCOM initially, and cite the source for that one note.

[Note to self: This needs testing and work to reflect newer versions. This text not yet revised for Version 8 and later which I believe had changes in this area.] One can make a “template” data set with all the custom tags, flags, etc. that you use. This would become the “master” of these custom choices. (In Version 4 you needed to create a dataset with one person. You performed a List of People filtered for one person whose output creates a new dataset. Then you deleted events and sources as needed concerning that one person, and renumbered the person ID to 1.) For Version 5, in a Project that has a dataset with all your desired custom elements, use the Data Set Manager to “Add” a dataset to this project. The screen will ask you to name the new “template” dataset, and identify the existing dataset with the custom elements and select which custom features to copy from it. This new “template” dataset can now be merged into the desired person dataset (or vice versa) once it is in the same project. Unfortunately, Accent files relying upon custom flags are identified by dataset number within the project20, not by the name of dataset. If you have saved accents or renumber the dataset, you will need to recreate your accents.

[Note to self: Need to test and expand this documentation on this idea from TMG ListServ]

1. Create a new empty data set that includes all your data types of the dataset you want to move to.
2. In the data set you want to move from, start a new Focus group.
3. Insert every person you want to move into the Focus Group.
4. When everybody is in the Focus group, go to Add --> Copy Person(s).
5. In the Copy window, select “Copy the people in the current Focus Group”. Then, in the “To data set” window, select the new empty dataset. In the “Data types to include” tab, select all the data types.
6. Select “OK” and the Focus Group people will be added to the new data set.
7. Now merge the new dataset to your target data set.

Note: It may be possible to copy the Focus Group directly to the target data set but I did as above so that I could check the new data set after the Focus Group was moved.

While the Check for Duplicate People function (Tools menu) is designed to identify possible duplicates for merging, I find it offers too many possibilities. Most of the time the people to merge will have similar names. Thus I choose to use the Expanded Picklist (F2 or binoculars with Preferences > Program Options > Lists set) to look for possible duplicates as it displays multiple columns of data and/or the list of a person’s events. I generally filter to primary names only so a single person does not appear multiple times with their multiple names, and sort by Soundex Surname. You cannot merge people when they are in different Data Sets (watch the ID number), or when they are actually the same person as shown by the ID number (as with multiple name variations shown in the PE if you forget to display primary names only).

Once two people are identified, use the Merge Two People option on the Tools menu. Keep all links as part of the merge (i.e. marriage, parent/child) and wait to delete the extras (two sets of parents, two Name-Var tags, etc.) later in the person view of the merged person. The combined person will have the ID#, and all the flag settings, of the person shown on the left side of the screen. When there are duplicate tags, those of that person will be marked as primary. If you want the person on the right side to override and remain and be primary, click the Flip button to reverse them. I prefer to change the colors (Preferences > Program Options > Colors) on the Merge People screen to contrast (green for the person to keep on the left and red for the person to be merged/deleted on the right). This provides a natural clue as to which person’s settings will remain and prevail when there are conflicts.

Start with farthest back people (ends of trees) and merge all of them first. Use a List of People report with a filter of “Father* ID=0 AND Mother* ID=0 AND PSEUDO=N” and set a custom flag (e.g. 1WORK) as candidates as secondary output. This first flag setting may also want to filter on a flag specifying names of interest to limit the number of candidates Then change the flag value as you consider them showing they are merged/edited.

Next identify all children where any parent was a candidate and set a new flag for them, and unset the old flag from the parents. This takes several steps:

1) LOP with filter “1WORK <> N” with Descendants set to one generation, and set a new custom flag (e.g 2WORK) as secondary output.

2) LOP with filter “1WORK <> N” without Descendants, and unset the new custom flag.

3) LOP with filter “1WORK <> N” without Descendants, and unset this custom flag.

Either now take the two steps to set the first flag to the value of the second and unset the second, or when ready for the next generation do the above with the two flags reversing their meaning.

This flag can then define a Focus Group or a filtered picklist or PE list and merge them changing their flags as you go, etc. Doing it in this order from parent to child ensures that you do not merge a child until all/both parents are merged and automatically merges the duplicate children to the merged parents rather than leaving you with two sets of parents.

• Insure the primary name is entered according to my standards, delete or modify one of the two Name-Vars from the merge.

• Be sure I have both a standard Name-Married and my custom Name-Marr-Title Name tag for married woman

• When multiple events are described in a single tag, separate them into appropriate tags

• Clean up Places using my F2 sort entry to ultimately eliminate Master Place List entries that do not conform to my location standard. Some of this may have been accomplished by first cleaning up the Master Place List above

• Examine dates in the time range of “Old Style” entries and verify that the date was correctly entered if possible

• Verify that the LIVING flag and my several custom flags (PSEUDO, etc.) are correctly set

Be careful about deleting apparently identical event tags. Check for differences in Citations, Witnesses, Place, Memo, etc. Open the Citation in the tag to be deleted, then close it by clicking the OK button, or pressing F9. This copies the Source number and Citation Detail to the “Repeat” list. If present, the Citation Memo and Reference field are also copied. Now, open the tag to be kept, press F4 to open a new Citation, and then press F3 to recall the saved citation from the Repeat list. If the Citation Memo and/or the Reference field were present, place the cursor in those fields and press F3 again to recall their contents. Sureties, if used, have to be entered manually. Copy dates or text using Windows copy and paste. Finally, just delete the unwanted tag.

[Note to self: Need to test and incorporate these ideas in the appropriate sections of this chapter]

Confirm the potential to merge these person by looking at the side-by-side merge persons screen. If you are happy merge them to the lower ID person (but don’t eliminate any tags, especially any Marriage or Child relationships). The Detail View now will have mixed accents on it. Change the custom flag of that person from 1 to M - this marks the person as having been merged.

Once you have dealt with the obvious merge candidates, then look at the remainder. If you find a person who does not appear to be in both data sets, then change their custom flag to C (as there is no cleaning action needed). You will also find persons that you think are duplicates but it doesn’t make sense (because the surname was totally misspelled in one data set relative to another - in my case one Germanic surname commenced with ‘F’ and the other ‘P’ - soundex doesn’t help here!)

When you have completed this process over all persons (that is the Expanded Picklist is only at the colour for state M or C of your flag), then you start on the next process. For persons at state M examine their Detail View and consolidate the tag information (usually only requires deleting of duplicates, but beware of the differences in sureties, citations, exhibits, witnesses, and sentences in tags that display identically in the Detail View). When you complete this operation change their flag value to C.

As you can’t be sure about inter-cousin marriages and other witnesses for persons to be in either data set, I would advise _NOT_ trying to find a small set of persons in one data set and progressively do many smaller cycles of this process on a family line by line basis. It is much less likely that you will not break any relationship links if you combine all your data into a single, but jumbled, data set and then work methodically through it.

It is possible to check the relationship differences between data sets for specific family lines by creating a Descendant Indented Chart for nominally the same person in each data set - use the end of line person as the focus.

When editing for merging keep in mind your chosen data input standards for locations. All fields of two or more locations must be edited in the Master Place List to identically match for them merge, including comments, styles, etc.24 You must do a File>Maintenance>Optimize [was “Reduce size of Admin Files” in Version 4.0] after completing the editing to actually cause the merge and to remove unreferenced locations. Optimize will fail25 to recognize two places as identical if there are more than 99 characters in any one place field and those leading characters match. As part of editing you can shift all locations left or right in a given entry by selecting the end location subfield in the entry and using Ctrl+arrow.

You can see all events associated with a candidate place for merging using the Events button on the MPL. To create a report that will identify all events with an input place to aid in clean-up, use the List of Events report with Focus filter of “Place contains [?]”.

Sources are merged using the Merge button on the Master Source List and specifing the source number of the two sources. The merged source will have all citations from both sources linked to it, and will use the output forms/templates of the remaining source. This merge can also be used to change one source into a new form. If any Source Elements are different in the two sources, the differing elements in the source being merged/deleted will be lost. Be sure that the Source Elements in the two sources are identical before merging. If you merge two sources, each linked to the same repository, source for this source, exhibits, and/or tasks, you will end up with all of these linked to the resulting source. This may result in duplicates, such as the same repository linked twice (one marked primary and the other not if both were marked primary before the merge). It’s up to you to clean up the merged source for any of these which are duplicates. While a source can be linked to multiple repositories, only one may be marked “primary”, and that is the only one that will appear in reports, so may actually want separate seemingly identical sources if there is something different to say about them in each repository. If source Pseudo people are used, remember to also deal with them.

If you have multiple source types (possibly from an import) that you want to merge to a given source type, temporarily set the one source type you want the others to be changed/merged into as the “Primary” source type by selecting it and clicking the Primary button. Then delete the similar but undesired source type(s). This will not delete the sources that were instantiations of those source types. Any sources that used the deleted source type are re-assigned automatically to the current “primary” source type, but the definitions of those sources are not altered. Repeat as needed for the unwanted source types. Remember to change the “Primary” back to something that makes sense to you when you finish, and reoptimize the project files.

When merging two repositories using the Merge button on the Master Repository List, all source links, exhibits, and/or tasks assocated with one repository will be transferred to the other repository and the first deleted. All information in the definition of that first repository (e.g. Name, Address, Memo) will be lost; none of this information is merged with or overwrites the information in the repository being retained. Any sources linked with a Repository Reference will retain that reference, but will now be linked to the other repository. Any sources which were linked to both repositories before the merge will retain both links. After the merge both links will be to the same repository, with possibly differing references. If one of the links was Primary it will remain Primary but possibly now a link to the merged repository. A filter specifying the merged Repository AND Number of Repositories is greater than one on a List of Sources report will help in identifying any such sources with possibly duplicate repository links.

GEDCOM (an acronym standing for Genealogical Data Communication) is an open de facto specification for exchanging genealogical data between different genealogy software. GEDCOM was developed by The Church of Jesus Christ of Latter-day Saints (LDS Church) as an aid to genealogical research. Version 1.0 was originally specified in 1984. TMG import and export will only allow GEDCOM files based on either Version 4.0 (specified in 1989) and Version 5.5 (specified in 1995). A Version 5.5.1 specification was released in late 1999 which enhanced Version 5.5 with nine new main GEDCOM tags, several new GEDCOM subtags, and other changes. Most current genealogical programs provide import and export based on this updated specification, but neither the standard TMG GEDCOM export nor the Enhanced Export added to TMG in 1994 are based on it. Since the GEDCOM export tag type for a custom TMG tag type can be set on the Other tab of the Tag Type Definition screen users may mistakenly believe they could specify a GEDCOM tag type for export new to Version 5.5.1. But since that name will be an undefined or unallowed GEDCOM tag type in either of the two GEDCOM Versions able to be specified for the TMG export, TMG will not export any tags of that TMG tag type. Thus all comments below are restricted to those two GEDCOM versions.

The TMG export wizard provides options for some types of information to select whether that data will be exported. If data begins with an exclusion mark ‘-’ it will not export unless that option is set, but the TMG tag will still generate a GEDCOM tag. For example a TMG Note tag which only has an excluded memo will generate a completely blank GEDCOM NOTE tag. However, if the export option “Show Excluded Data” is selected, the output will include the leading dash. Data that begins with double exclusions or data within text marked [HID:][:HID] is never exported.26 All parts of split memos27 are exported complete with their double bars, even if a particular part other than the first is marked with single or double exclusion marks. Sensitive data (text surrounded by sensitivity braces ‘{‘ and ‘}’) will only export if that option is selected, and the braces will be stripped unless requested to remain by selecting the export option “With Markers”.

All embedded text format codes (e.g. [ITAL:]text[:ITAL], [BOLD:]text[:BOLD], etc.) as well as the HTML format codes (e.g. [WEB:]url;text[:WEB], etc.) are removed and not exported, but the text within them is exported. See below concerning the embedded citations codes.

Beginning with TMG Version 5, options were introduced which permitted selecting a subset of individuals within a dataset by first selecting a dataset, then selecting a subset of individuals that is defined either in the Project Explorer or in a saved Focus Group (max 40 character name).

Regardless of which Place fields are selected for export, the export uses only the following fields of a Repository: Name (Other); Place: Detail (not Addressee), City, State, Postal, Country, and Phone; and the Repository memo. A full GEDCOM repository record output from TMG will be:

The GEDCOM specifications identify maximum allowed text lengths for each of these fields as:

The GEDCOM specifications generally expect an ADR1 tag subordinate to the ADDR tag similar to City, State, etc. data as the location of the address detail, but TMG places this data directly on the ADDR tag. (See also the Version 9.04 Enhanced Export Option below.) An ADR1 tag has the same maximum field length as the ADDR tag. TMG will export to the length it allows as input up to the maximum specified GEDCOM line length. Importing programs are within their rights to not allow longer text and/or to truncate any data in these fields to these maximum lengths.

While an ATTR tag existed in GEDCOM 4.0 which could be used for custom flag values, in GEDCOM 5.5 the ATTR tag no longer exists. The only other option is the GEDCOM ATTRIBUTE_TYPE, but that is now a fixed list. As such, TMG Flags are not exported.

Certain project/dataset information is not exported. The dataset file name could be under HEAD as the GEDCOM FILE tag. Also the full name of the TMG project could be in a NAME tag subordinate to SOUR in HEAD. The contents of the user’s dataset memo (.DOC file) could be exported as a NOTE tag under HEAD. However, none of this is exported by TMG.

TMG exports its ID number of the individual in the TMG dataset as their GEDCOM INDI number in the output file. That permits a direct correlation between the GEDCOM file and the original dataset. Some importing programs will use the GEDCOM INDI number as the ID number of the record created from the GEDCOM file. However, if there are gaps in the sequence of TMG ID numbers, some importing programs may have problems with the missing numbers or give errors. The GEDCOM specifications require the INDI number to be unique within this file, be surrounded by the at-sign character ‘@’, not begin with a number sign ‘#’, and not contain either a colon ‘:’ or exclamation ‘!’ character. If your project has multiple datasets the displayed TMG ID number usually is preceded by the dataset number and separated by a colon, e.g. (2:94). Since you can only export from one dataset at a time, and the INDI number cannot contain a colon, the dataset number is not exported as part of the GEDCOM INDI number, e.g. @I94@. For additional output of those TMG ID numbers see my GEDCOM recommendation number 5 below.

The GEDCOM specifications define the construction of the entire name which is required to be on the GEDCOM NAME tag entry as:

These specifications state that TEXT2 is identified as the entire Surname since it is between slashes. Any of the three parts can be empty/missing but the slashes are expected. While TMG will infer empty name fields from the Primary Name tag for its reports, whether blank name fields in the GEDCOM output are inferred depends upon the “Name NPFX/NSFX” TMG Export option. If the GEDCOM Export option “Name NPFX/NSFX” is not checked, the subordinate namepart records for the NAME tag are not created, but if either TEXT1 or TEXT2 would be empty the NAME tag will include all inferred values for that otherwise empty field.28 With the GEDCOM Export option “Name NPFX/NSFX” checked, no name fields are inferred even if TEXT1 and/or TEXT2 would be empty, and TMG will separately export up to six non-empty subfields from a TMG Name tag as:

When constructing the complete name for the GEDCOM NAME tag the TMG Export combines the prefix and given in TEXT1 separated by a space, combines presurname and surname in TEXT2 separated by a space, and only puts the suffix in TEXT3.

Although defined in GEDCOM, even if the TMG Name-Var tag is Name-Nick, TMG does not export anything into the NICK GEDCOM namepart. Neither the “OtherName” field, nor either of the sortname fields are exported.29 If the TMG Name tag has a memo or citations these will export to GEDCOM. But the GEDCOM NAME structure does not define a DATE namepart, so the TMG Date field will not export. (See also the Version 9.04 Enhanced Export Option below.)

While the GEDCOM specifications allow multiple NAME tags for an individual, they include no mechanism to assign a specific NAME tag to be associated with a specific event. Thus this linkage feature in TMG is lost on export.

Regardless of the setting of the GEDCOM Export option “Name NPFX/NSFX”, the TMG “Title” Name field does not export as part of the GEDCOM NAME structure. Instead that TMG Name subfield always exports to a separate GEDCOM TITL tag. While GEDCOM does define a TITL tag type, that TITL event GEDCOM structure originally was designed to record the event upon which the title was granted.30 None of the TMG’s structures can produce a full GEDCOM TITL event structure, as the export of both TMG Name tags and Event tags have export limitations. A TMG Name type tag has no option to enter a Location so cannot export it, and the GEDCOM NAME tag has no option to include a DATE. (See also the Version 9.04 Enhanced Export Option below.) A TMG Event type tag can have both a Location and a Date, but it will export the entire memo even if split as the TITL value, so cannot export a separate memo.

A TMG custom Title-Event tag type in the Other group with a memo limited to the text of the title, and its TMG GEDCOM Export tag type set to TITL, would export closest to the defined intent of the GEDCOM TITL tag type. But such a custom event will have no recognition in TMG as being part of a name. As the Date (might be included by the Enhanced Export) and Location might be included as text in the memo, a Name-Title tag type in the Name group which only includes the Title text seems the best compromise for both TMG use and GEDCOM export.

If the GEDCOM Export option “Name NPFX/NSFX” is checked and there is data in more than the TMG Title field, both a GEDCOM TITL and a NAME tag will be exported.31 The TMG Title field is exported as the GEDCOM tag TITL but that TITL tag will not include the memo and/or citations. The separate NAME tag will include the other name fields and any memo and/or citations. A TMG Name tag that only has data in the Title field will export only a TITL tag for the Title field text which will include the memo and/or citations. Unfortunately because of creating two separate GEDCOM tags, subsequent import of a TMG exported name structure with a title is not symmetric and will not reconstruct the single TMG tag which produced those two GEDCOM tags.

If the GEDCOM Export option “Name NPFX/NSFX” is not checked and there is data in more than the TMG Title field, both a TITL tag and a second tag (either a NAME or another TITL tag)32 will be created, both will contain the memo and/or citations, and the second tag will have inferred name values. Even when the option is not checked, a TMG Name tag that only has data in the Title field will export only a TITL tag for the Title field text which will include the memo and/or citations.

For both export and import there is a one-to-one relationship of the TMG standard date modifier codes and a GEDCOM date modifier as follows:

TMG Code	TMG Term	GEDCOM Code
0	Before	BEF
1	Say	EST
2	Circa	ABT
3	Exact	(no modifier)
4	After	AFT
5	Between	BET d1 AND d2
6	Or	EITHER d1 OR d2 *
7	From…To	FROM d1 TO d2

*The date format of EITHER…OR… is not defined as valid in the GEDCOM specifications. However, this GEDCOM format is what TMG’s final Version will produce on Export from its Or Date format. Symmetrically TMG will convert that invalid GEDCOM format upon Import to its TMG Or format. Hopefully the importing program will also accept this non-standard exported GEDCOM format on Import, or at least produce a message indicating an invalid format.

There are two additional legal GEDCOM date forms which are not exported by TMG’s standard date codes: CAL and INT. However, TMG’s irregular date format can accomodate both import and export of those two GEDCOM date forms, up to the maximum of 29 characters allowed in TMG’s irregular dates. If the GEDCOM file has either of these forms, TMG will import it, but will make it an irregular date, truncating to 29 characters if necessary. For example, the GEDCOM CAL (calculated mathematically) date form:

And a TMG irregular date of exactly that text will symmetrically export as the legal GEDCOM CAL date example shown.

A GEDCOM INT date means “interpreted from knowledge about the associated date phrase included in following parentheses”. Since the INT date phrase is often long, it will likely be truncated on import, e.g. the example GEDCOM INT date:

is truncated to TMG’s max length of 29 characters to become the TMG irregular date of:

However the GEDCOM Import log will indicate that truncation. But a TMG irregular date where the phrase and parens will fit in 29 characters can be used to export a legal GEDCOM INT date. For example the TMG irregular date of:

Most TMG Master Place Records are exported the same way, duplicated as part of every tag to which that place record is linked. (But places linked to a TMG Repository Definition are exported very differently as described below.) The export creates a GEDCOM PLAC record subordinate to the GEDCOM record for that tag. On the TMG Export Wizard option screen for “Reference field, exclusion and place choices”, which fields to export from a linked Master Place Record can be specified. But this option applies to the export of all place records regardless of its TMG Place Style. All the selected fields will export in the TMG heirarchy order (L1 thru L10) as the comma separated text of that subordinate GEDCOM PLAC record. I highly recommend selecting the option “Commas When Missing”, otherwise it will be impossible to tell in a PLAC record what text originally came from which TMG place field.

The GEDCOM specifications only define two types of records associated with people: Individual records and Family records. There is no definition of a general “two-person” record. Family records are used to describe “marriages, common law marriages, and family unions caused by two people becoming the parents of a child”. A Family record is created for the two individuals being designated as explicitly married or share parenting a child, and the two individuals are identified by the HUSB and WIFE entries in the GEDCOM Family record. “The family record structure assumes that the HUSB/father is male and WIFE/mother is female.” Family events within the GEDCOM Family record thus are shared by these two individuals. Individual records are “a compilation of facts, known or discovered, about an individual”. Individual events within the GEDCOM Individual record apply only to this one individual. TMG tags can only be exported as an event within one or the other of these two types of records. Either the event must be within a Family record relating to both the “husband” and “wife” of the “family union” or within an Individual record associated with only one person. This is the explicit design of the GEDCOM 5.5 specs. Only family events are defined by the GEDCOM specifications as relating to two Principals, all other GEDCOM events have no mechanism defined for anything but one Principal. (See also the new Enhanced Export option below for a custom mechanism to link Witnesses to an event.)

If the two Principals assigned to a TMG tag are married or share parenting a child, and the export GEDCOM event type for that TMG tag type is defined as an expected or potential Family event (see the list of GEDCOM event types below), then the TMG tag will be exported as an event within the Family record of that family union. Such tags will not be exported as part of the Individual records of either of the two Principals.

If the two Principals are not married nor share parenting a child, and the export GEDCOM event type is defined as an expected or potential Family event, the tag is not exported in any way. TMG excludes the entire tag from the GEDCOM output.33

TMG tag types with only one Principal set to export as an expected or potential Family GEDCOM tag type involve special conditions. Some GEDCOM tag types are expected to be GEDCOM Family events and have two Principals, such as the default export of standard tag types in the TMG Marriage and Divorce groups plus Annulment. Some GEDCOM tag types potentially can be either Family events or Individual events. TMG appears to deal with such one-Principal tags differently depending upon their group.

• Standard one-Principal TMG tag types which are set to export as GEDCOM tag types expected to be GEDCOM Family events will still export as a Family event in a GEDCOM Family record which identifies only that one spouse.

• Custom one-Principal TMG tag types which are set to export as GEDCOM tag types expected to be GEDCOM Family events will not export.

• A one-Principal TMG tag type which is set to export as a GEDCOM tag type which potentially can be either a Family event or an Individual event will always export as an Individual event.

If the export GEDCOM event type for that TMG tag type is defined as a strictly Individual event (see the list of GEDCOM event types below), then the TMG tag will be exported regardless of the relationship of the two TMG tag Principals and regardless of the number of Principals. If there are two Principals, the single TMG tag will become two GEDCOM Individual events, a duplicate created within each Principal’s Individual GEDCOM record. However, any indication of a linkage of the two Principals to this identical event is lost in the GEDCOM output.

TMG tag types set to export to GEDCOM as 1 EVEN 2 TYPE deserve special mention. EVEN is a catch-all name for “event” and is the default GEDCOM export tag type for custom tag types in TMG. The TMG tag type Name is the fixed value to output in that GEDCOM event’s TYPE field.34 Since 1 EVEN 2 TYPE events are among those which are potential Family events, the export actions for those types of events apply. Thus if there are two Principals who are married or share parenting a child, the tag will export as an event within a Family record. If the two Principals are neither, the tag will not export. If there is only one Principal, the tag will export as an Individual event. Because of this most of my custom tags with two unmarried Principals which are set to export as 1 EVEN 2 TYPE, like my Census tags (e.g. the two Principals HOH and Census person never share a child), are not exported.

Whatever the situation with the Principals, the GEDCOM export tag type for a custom TMG tag type must be set on the Other tab of the Tag Type Definition screen either to a existing allowed GEDCOM tag type, or to the generic 1 EVEN 2 TYPE event type. If the TMG export option is explicitly set to a named but undefined or unallowed GEDCOM tag type, that TMG tag type will not export.

With the ability to output Witness links using the new Enhanced Export option, users may wish to change the linkage of one of the two “non-family” Principals to be a Witness to the tag instead of a Principal using an appropriate role. With that change the linkage of both individuals to this one GEDCOM event will be retained within the enhanced GEDCOM output. A List of Events report can identify all TMG tags in a project which have two Principals with a filter like:

I suggest including in the report’s output columns the Column Types of “Tag Type Group” and “Tag Type Label” as the first two sort fields, along with at least “Prin1 ID” to identify the specific tag. With this report sort, those tag types which are expected to be GEDCOM Family events and have two Principals (such as those in the Marriage and Divorce groups plus Annulment) can be quickly identified. The TMG tag types which potentially might be accepted as GEDCOM Family events (depending upon the two Principals being married or parenting a child) are any TMG tag types which output as 1 EVEN 2 TYPE plus those with a default GEDCOM tag type which is identified as both an Individual and Family event in the list of GEDCOM tag type names below. These standard TMG tag types include by default: Anecdote, Association, Census, Event-Misc, History, HTML, Illness, JournalConclusion, JournalIntro, Living, Military-Begin, Military-End, NarrativeChildren.

There are several export limitations concerning relationship tags. TMG will only export Primary relationship tags. Neither the memo nor the citations on the Primary relationship tags will be exported. While GEDCOM 5.5 has no structure for citations directly on its relationship tag types (i.e FAMC or FAMS) so none are exported, it does have the capability to include a memo/note, but TMG does not export it.35 Further all primary relationship tags will be exported as if they are birth/genetic relationships, regardless of the TMG relationship tag type. Although the GEDCOM 5.5 definition of the FAMC tag structure allows the nature of that entire family relationship (implying both father and mother) to be defined as one of four types using a PEDI qualifier tag (defined values: adopted, birth, foster, sealing), TMG does not use the PEDI qualifier on export.36

No non-primary relationship tags will be exported37 even though the GEDCOM 5.5 standard does define a method to allow a child to be linked to multiple family structures using multiple GEDCOM FAMC tags. However GEDCOM considers all of those linkages to be (potential) biological relationships.

First, TMG will only include in the export those sources linked to some person or tag which is exported, and those repositories which are linked to exported sources. If the source is not cited, it is not exported. As specified in TMG HELP: “If the citation detail is split, only CD1 is exported.” Further CD1 is placed in the GEDCOM PAGE subtag under the SOUR tag reference. The GEDCOM specification limits PAGE text to a maximum of 248 characters. One Wholly Genes Forum post suggested choosing to restrict one’s memo data entry use to CD2 through CD9 for TMG output template purposes. Then with the Citation Preview option38 one could copy the created Full Footnote text and paste it into CD1. That way the TMG templates could be used, but the Full Footnote text (if it did not exceed 248 characters) would export to GEDCOM.

Since GEDCOM has no subtag for a Citation Reference, if the Export options specify to output the Citation Reference TMG will export it in the GEDCOM PAGE subtag following the Citation Detail text which is in that GEDCOM subtag separated by a semicolon. The combined export may still be limited to the maximum of 248 characters.

The entire citation memo will be exported to GEDCOM in a NOTE subtag, possibly with continuation lines, under the SOUR tag reference. If the citation memo is split, all parts including the separator bars will be exported. If the CM is not otherwise used in TMG source templates, the Full Footnote preview text could be copied and pasted to that TMG field for GEDCOM export.

Any embedded citation which is included in a TMG Tag Memo will not export. All the text between the embedded citation codes, including the codes, will not appear in the GEDCOM NOTE tag, nor will there be output a source citation to that source.

There is an option in the Export Wizard to export citation Surety values to GEDCOM.39 I don’t use Surety so have not extensively tested this feature. However, the QUAY tag produced by this option can only accept one integer value, and the only values defined are 0, 1, 2, and 3. TMG will export only the P1 Surety as the QUAY value, and will not export a QUAY tag if the P1 value is either blank or a minus sign ‘-’. (See also the Enhanced Export option concerning Sureties.)

(Much of the following was based on the Considerations for Exporting Sources to GEDCOM Files web page posted by Terry Reigel on his Terry’s TMG Tips web site. However, I have modified and selected those parts appropriate for my chapters, and personally tested the behavior described below.)

The GEDCOM citation points to a separate GEDCOM source record structure which is considerably more limited in capability than TMG Source records. There are only five main GEDCOM elements in the SOUR record to contain all the actual data about the source, plus a few elements in the REPO record. In contrast TMG has 31 different Source Element Groups which can contain variable data about the source and repository, although a single TMG source can only include 23 of those elements.

In some cases the TMG Source Element name/alias used in this source definition can output, plus there can be additional fixed data entered as text output from the source templates.40 TMG attempts to squeeze all these 31 elements and these names/aliases into the limited GEDCOM source elements. Numerous alternate names/aliases for a TMG Source Group can be defined, called Source Elements. But for all groups there is one standard Source Element name which is essentially identical to the name of the Source Element group. That name is used for clarity in the table below, but the Source Element alternate name/alias is in some cases also output as text in that GEDCOM field.

The TMG fields potentially exported into each GEDCOM SOUR record field are listed below. Multiple TMG fields output into a single GEDCOM field are output in the order shown, separated by commas unless otherwise specified. Fields marked with the superscript code SE below are output preceded by the TMG Source Element name/alias used in that source definition ending in a colon. When multiple fields could output in a single GEDCOM field, any fields whose text contains commas and/or colons can make it difficult to tell when one field ends and another begins. Fields which are not marked with SE below and thus are not identified by their Source Element name make it especially unclear whether the text is from such an additional field, or was simply part of the text being output from the preceding TMG field. Since any field not marked with SE below does not output it’s alternative Source Element names/alias, such names will be lost in the GEDCOM export. If a GEDCOM field can contain multiple fields and the first or only field output is marked with SE below, the field will begin with that name/alias.

Abbreviation (if no Short Title); otherwise Short Title, Short Subtitle (separated from a Short Title by a colon, not output if no Short Title)

Abbreviation (only if otherwise empty), Title, Subtitle (separated from a Title by a colon), Record TypeSE, SubjectSE, Second PersonSE, LocationSE, Second LocationSE, SeriesSE, EditionSE, VolumeSE, VersionSE, PagesSE, File ReferenceSE, Film NumberSE

Publisher, Publisher Location, Date, Second Date (Source Element name is separated from the date by a comma)

If a TMG source definition has a repository linked on its Attachments tab, that GEDCOM SOUR record will in turn point to a separate GECOM REPO record which will export the details of the one TMG Repository linked as primary. If multiple repositories are linked to this source, only the link to the primary is exported. A Repository definition will only be exported if it is linked as primary to some source which is exported. If the TMG “Name-ID #” field in the repository definition has an ID number of an individual as the repository, the REPO subfield of the SOUR record will link directly to that individual’s GEDCOM record. A separate GEDCOM REPO main record is not created for such a Repository Definition, so anything else entered in any field of that TMG Repository Definition is lost in the export. A Repository Abbreviation is never exported, even if the Name-Other is empty.

Repository Name-Other (if that field is empty, the word “unknown” is output as the name)

Non-empty TMG address fields L2, L3, L5, L7, and L8 from the repository definition. If non-empty only these will be exported, and there is no option to export more or fewer place fields. (See also the enhancements to the Repository Detail place field when the V9.04 Enhanced GEDCOM Export option is used.)

Many standard TMG tag types are set to export as a specific GEDCOM tag name which is not included in the strict GEDCOM 5.5 specification. Even though they are the TMG export default, none of them (marked with the superscript code NO in the table below) will export since the GEDCOM tag type is unrecognized. All of their event data will be lost on export if their GEDCOM export tag type is not changed to a recognized name, or to 1 EVEN 2 TYPE. Because I generally prefer to strictly adhere to the GEDCOM 5.5 specification as well as try to avoid loss of data, I usually modify such TMG Tag Types in the Other tab of the Tag Type Definition to avoid its unrecognized tag name and use the general purpose 1 EVEN 2 TYPE structure for GEDCOM export:

Any program accepting GEDCOM 5.5 should accept these generic definitions as custom events. This is also the only mechanism to retain the custom TMG tag type Name. If multiple TMG tag types are set to export to the same specific defined GEDCOM tag name, their different original tag type Names are lost. My table of the definitions of my custom tag sentences includes in the header of each tag type the GEDCOM tag name I have set for the export of that tag type.

Some standard TMG tag types export to a defined GEDCOM tag name, but do not or cannot export all the data which may be stored in the TMG tag type. A major example is the TMG Note tag type, which by default exports as the defined GEDCOM NOTE tag type. The entire memo will export as the text on the NOTE tag with possible CONC tags if necessary. But neither the Date nor the Location will export. (See also the Enhanced Export option below for custom output of the Date. That produces tag names with a leading underscore character, which is the naming method defined by the GEDCOM specification to identify a non-standard tag name.) I also recommend these GEDCOM export tag types specified in the table below be changed to 1 EVEN 2 TYPE so that all the TMG data will export. However, be aware of the affect this may have on such tags if assigned two Principals as described above.

The following table lists the TMG Tag Types which are included in a “New” project41 and the default GEDCOM tag type which they are set to output by default. Projects upgraded from earlier versions may have older and thus different defaults. The Notes in the table below indicate whether this GEDCOM tag type is a standard tag type defined in GEDCOM 5.5.

GEDCOM Family events generally assume/require two Principals who are either married or share parentage to a child. See the comments above about two Principal events.

Any TMG tag type, standard or custom, whose GEDCOM Export option is set to export as a TMG recognized Individual GEDCOM Attribute event can be affected by the TMG Export Option “Extract recognizable memos as tags”. If this option is not selected, the tag will export according to the GEDCOM tag type set in the TMG Tag Type Options. But if this option is selected and TMG recognizes the first word of the tag memo as one of TMG’s recognized Individual GEDCOM attribute Event names followed by a colon, then TMG will export using that GEDCOM tag name instead of the GEDCOM tag type specified for this TMG tag type. (Unfortunately the two Individual GEDCOM Attribute event names which do not have defined TMG tag types, INDO and PROP, are not recognized in the memo by use of this export option.)42 All the memo text following the colon will output, using GEDCOM CONC lines if necessary. Any blanks immediately following the colon are stripped. Historically this feature was introduced to deal with data imported from early PAF versions where “tags” were recorded in memo fields in the form: TAGNAME: data. Since both the GEDCOM export tag type specified for this TMG tag type and the tagname in any memo using this option must be recognized Individual GEDCOM Attribute event names, there now seems little value to this option. For example to create an Individual GEDCOM Attribute Event of NATI, a custom TMG “MyTag” tag type simply needs to be specified to export as the recognized Individual GEDCOM Attribute Event NATI. If the option is not set the GEDCOM tag will use the TMG tag’s memo as the data. However if this option is set, “MyTag” might be specified to export as the recognized Individual GEDCOM Attribute Event DSCR. But if the memo of a tag of that type begins with the text: NATI: text , a DSCR GEDCOM tag will not be output. Instead a NATI tag will be output as:

The output of a different GEDCOM tag type than what is specified for that TMG tag type can be confusing. This option might be useful in conjunction with the TMG tag type “Attributes” since its default GEDCOM export tag type is unknown. One could specify some recognized GEDCOM Attribute Event such as DSCR for its GEDCOM export tag type. Then one could always enter TAGNAME: data in the memo of this TMG tag type, and setting this option would produce whatever GEDCOM Attribute Event tagname was desired. However, this seems unnecessarily indirect and does not seem to work in all cases.

The TMG tag types marked in the table below with a superscript code LDS will be hidden if the “Show LDS tag types” option is unset on the Master Tag Type List. As mentioned above, the TMG tag types whose GEDCOM tag type is marked with a superscript NO should be changed to export as the generic GEDCOM 1 EVEN 2 TYPE tag type since TMG will not export that tag type as there is no defined GEDCOM tag type of that name. The TMG tag types marked with a superscript code # should be used with caution as some of the TMG event information will be lost on export. They also may be good candidates to export as the generic GEDCOM 1 EVEN 2 TYPE tag type. The two standard GEDCOM event tag types CHRA and CREM which have no standard TMG tag type are good candidates for creating TMG custom tag types43 with their export set to these GEDCOM tag types.

TMG Tag Type	GEDCOM Tag Type	Notes
Address	ADDR NO	Not a defined GEDCOM event, but a subfield of an event, similar to PLAC and PHON.
Adoption	ADOP	Standard Individual GEDCOM Event
AFN#	AFN	Standard non-event GEDCOM tag type. There is also a TMG Export option to produce this tag using the TMG Reference Field data.
Age	AGE NO	Not a defined GEDCOM event, but defined by GEDCOM as a subfield of an event, or of HUSB/WIFE in a family record, to specify the age at the event.
Annulment	ANUL	Standard Family GEDCOM Event
Association		In earlier TMG versions the GEDCOM export tag type was set to ASSO, but that GEDCOM structure has a very different purpose than this TMG event tag type. As of Version 9.03 this TMG type is set to export as 1 EVEN 2 TYPE.
	ASSO	Standard non-event GEDCOM tag type for associating/linking two people together. TMG has no mechanism to produce the special data structure required by GEDCOM for this tag type.
Attributes	ATTR NO	Not a defined GEDCOM event or keyword.
Baptism	BAPM	Standard Individual GEDCOM Event
BaptismLDSLDS	BAPL	Standard LDS Individual Ordinance GEDCOM Event
BarMitzvah	BARM	Standard Individual GEDCOM Event
BatMitzvah	BASM	Standard Individual GEDCOM Event
Birth-CovenantLDS	BIC NO	Not a defined GEDCOM event but defined by GEDCOM as a value for the STAT subfield of the SLGC event
Birth	BIRT	Standard Individual GEDCOM Event
Blessing	BLES	Standard Individual GEDCOM Event
Infant BlessingLDSLDS	BLSL	Standard LDS Individual Ordinance GEDCOM Event
Burial	BURI	Standard Individual GEDCOM Event
CancelSealLDS	CANC NO	Not a defined GEDCOM event or keyword. The full word “CANCELED” is used as a value for the STAT subfield of the SLGS event
Caste	CAST	Standard Individual GEDCOM Attribute Event
Census	CENS	Both a standard Individual and Family GEDCOM Event
Christening	CHR	Standard Individual GEDCOM Event
	CHRA	Standard Individual GEDCOM Event for Adult Christening. Not a standard TMG tag type.
Codicil	CODI NO	Not a defined GEDCOM event or keyword.
Confirmation	CONF	Standard Individual GEDCOM Event
ConfirmLDSLDS	CONL	Standard LDS Individual Ordinance GEDCOM Event
	CREM	Standard Individual GEDCOM Event for Cremation. Not a standard TMG tag type.
Criminal	CRIM NO	Not a defined GEDCOM event or keyword.
Death	DEAT	Standard Individual GEDCOM Event
Divorce	DIV	Standard Family GEDCOM Event
Divorce Filing	DIVF	Standard Family GEDCOM Event
Description	DSCR	Standard Individual GEDCOM Attribute Event
Education	EDUC	Standard Individual GEDCOM Attribute Event
Emigration	EMIG	Standard Individual GEDCOM Event
Employment	EMPL NO	Not a defined GEDCOM event or keyword.
EndowmentLDSLDS	ENDL	Standard LDS Individual Ordinance GEDCOM Event
Engagement	ENGA	Standard Family GEDCOM Event
Anecdote, Association, Event-Misc, History, HTML, Illness, JournalConclusion, JournalIntro, Living, Military-Begin, Military-End, NarrativeChildren	EVEN	Both a standard Individual and Family GEDCOM Event. Any TMG tag type can be set to export as the generic GEDCOM tag type of EVEN with a TYPE subfield having the TMG name of the tag type. The listed TMG tag types have this option set by default.
Excommunication	EXCO NO	Not a defined GEDCOM event or keyword.
Communion1st	FCOM	Standard Individual GEDCOM Event
GEDCOM	GEDC NO	Not a defined GEDCOM event, but defined by GEDCOM as a subfield of the header of the file defining the GEDCOM version used in the file. This TMG tag type is used by default on import for any unrecognized GEDCOM tag type.
Graduation	GRAD	Standard Individual GEDCOM Event
Birth-Illegtimate	ILLE NO	Not a defined GEDCOM event or keyword.
Immigration	IMMI	Standard Individual GEDCOM Event
	IDNO	Standard Individual GEDCOM Attribute Event for a national ID number. Not a standard TMG event and not recognized as a GEDCOM tag name in the memo.
Marriage bann	MARB	Standard Family GEDCOM Event
Marriage contract	MARC	Standard Family GEDCOM Event
Marriage license	MARL	Standard Family GEDCOM Event
Marriage	MARR	Standard Family GEDCOM Event
Marriage settlement	MARS	Standard Family GEDCOM Event
Misc	MISC NO	Not a defined GEDCOM event or keyword.
Name-Baptism, Name-Change, Name-Married, Name-Nick, Name-Variation	NAME	Standard Individual GEDCOM Name structure. See the separate comments above about exporting Names.
Namesake	NAMS NO	Not a defined GEDCOM event or keyword.
Nationality	NATI	Standard Individual GEDCOM Attribute Event
Naturalization	NATU	Standard Individual GEDCOM Event
Number of children	NCHI	Standard Individual GEDCOM Attribute Event
Number of marriages	NMR	Standard Individual GEDCOM Attribute Event
Note#	NOTE	Standard non-event GEDCOM tag type
NullifyLDSLDS	NULL NO	Not a defined GEDCOM event or keyword. “NULL” is used in the GEDCOM specification to indicate the absence of any text for the value. There is no apparent equivalent LDS event in the GEDCOM specification.
Occupation	OCCU	Standard Individual GEDCOM Attribute Event
Ordinance	ORDI NO	Not a defined GEDCOM event, but a field with a yes/no value in the header of the GEDCOM file to identify whether the submission should be processed for LDS ordinances. Thus the meaning of the TMG tag type is completely different from the meaning of the GEDCOM keyword.
OrdinationLDSLDS	ORDL NO	Not a defined GEDCOM event or keyword. Instead see ENDL or ORDN
Ordination	ORDN	Standard Individual GEDCOM Event
Passenger List	PASL NO	Not a defined GEDCOM event or keyword.
Telephone	PHON NO	Not a defined GEDCOM event, but a defined as a subfield of an event, similar to ADDR and PLAC.
Presumed cancelledLDS	PRES NO	Not a defined GEDCOM event or keyword. The full word “CANCELED” is used as a value for the STAT subfield of the SLGS event
Probate	PROB	Standard Individual GEDCOM Event
	PROP	Standard Individual GEDCOM Attribute Event for identifying possessions/property. Not a standard TMG event and not recognized as a GEDCOM tag name in the memo.
RatificationLDS	RATI NO	Not a defined GEDCOM event or keyword.
Rebaptism	REBA NO	Not a defined GEDCOM event or keyword.
Reference#	REFN	Standard non-event GEDCOM tag type. There is also a TMG Export option to produce this tag using the TMG Reference Field data.
Religion	RELI	Standard Individual GEDCOM Attribute Event
ResealLDS	RESE NO	Not a defined GEDCOM event or keyword.
Residence	RESI	Standard Individual GEDCOM Attribute Event
Restoration	REST NO	Not a defined GEDCOM event or keyword.
Retirement	RETI	Standard Individual GEDCOM Event
	RFN	Standard non-event GEDCOM tag type for a permanent record file number. Not a standard TMG event.
	RIN	Standard non-event GEDCOM tag type for an automated record ID. Not a standard TMG event.
	ROLE	Standard GEDCOM sub-tag defined only as part of a source citation to identify what role this individual played in the type of event which was responsible for the source entry being recorded. Not used by TMG. Used by some other programs for the non-standard purpose of identifying the role of a witness to an event.
SealChildLDSLDS	SLGC	Standard LDS Individual Ordinance GEDCOM Event
SealParentLDSLDS	SLGP NO	Not a defined GEDCOM event or keyword. The GEDCOM 5.5 standard only defines the SLGC event to seal the child to a family (i.e. both parents). There is no defined event of sealing a parent to a child.
SealSpouseLDSLDS	SLGS	Standard LDS Spouse Sealing GEDCOM Event
SSN	SSN	Standard Individual GEDCOM Attribute Event. There is also a TMG Export option to produce this tag using the TMG Reference Field data.
StakeLDS	STAL NO	Not a defined GEDCOM event or keyword. The standard only defines TEMP as a subtag of LDS ordinance, endowmen, and sealing events for the LDS temple code
Birth-Stillborn	STIL NO	Not a defined GEDCOM event or keyword. STILLBORN is a value accepted for the AGE field of any event, or the DATE field of an LDS ordinance event.
	TITL	Standard Individual GEDCOM Attribute Event for a nobility type title. Not a separate default TMG event. See the separate comments above about exporting Names.
VoidLivingLDS	VOIL NO	Not a defined GEDCOM event or keyword. There is no apparent equivalent LDS event in the GEDCOM specification.
WACLDS	WAC NO	Not a defined GEDCOM event or keyword.
Will	WILL	Standard Individual GEDCOM Event

I have not done extensive testing of the GEDCOM export of exhibits, either internal or external, as I do not choose to export exhibits to GEDCOM. (If I get a chance to do such testing I may update this article in the future.) One type of exhibit I have tested are internal text exhibits, which are not exported by TMG either attached to events or to sources. Exhibits is one of several areas in the GEDCOM specifications which is open to interpretation in how they should be represented. The specification does provide for “multimedia objects” within a GEDCOM file which are to be “encoded” as a “Blob”, but also has a rather short maximum record length for them. Since the GEDCOM file is primarily intended to be a text file, due to the ambiguity of the specification, and because exhibit files are often very large, I have found this an area which programs commonly do not implement.

I suggest it would be safer and more reliable to transfer exhibits separately as their original file types, rather than rely upon an uncertain GEDCOM “encoding” and “decoding”. Users also might consider John Cardinal’s TMG Utility to convert all their TMG internal image exhibits to external ones to make such a separate transfer easier. The only method I have used to export internal text exhibits from TMG uses the “Export” feature in the TMG Utility to export the Exhibit Log. Although that produces a single file of all the exhibits, it could be post processed. While I have not personally tried it, the documentation for Bryan Wetton’s program PathWiz! suggests it can create external text files from TMG’s internal text exhibits.

Even with the Enhanced Export option mentioned below, I do not recommend using GEDCOM to transfer your TMG data to another program if it can be avoided. Whenever possible a program which will directly import the data from the TMG project files themselves is likely to do a better job. By exporting to GEDCOM, too much is likely to be lost or require considerable post import cleanup. However if GEDCOM is the only option, the following may improve the ability to later import the GEDCOM file:

1) Use the Enhanced Export option if you are using Version 9.04 or later. (Or better yet use the new TMG to GEDCOM program.)

2) Set the GEDCOM export option to 1 EVEN 2 TYPE for all the TMG tag types which you use and are described in the above listing of GEDCOM Tag Names as having export issues. That export setting will insure that all data for such TMG tag types including dates and citations are exported as custom events. However, be aware of the affect this may have on such tags if assigned two Principals as described above.

3) Use the Secondary Output on a List of People report to change all Ancestor Interest (ANCI) and Descendant Interest (DESI) TMG Flags to 0 before export. Use a copy of your project to do this if these flags are useful to you in TMG. As these Flags are generally not recognized by other importing programs, this will remove numerous messages concerning them from an import.

4) When you select Surety export, do not select the SOUR sub-option. For some importing programs these extra tags cause problems. If you select the Enhanced Export option, this SOUR sub-option will be disabled as it will interfere with the custom export of TMG surety information.

5) In Step 5 of the TMG Export Wizard you can select the TMG ID numbers (the number assigned to each person in a data set) to export. As mentioned above, the GEDCOM INDI number will already be the TMG ID number. If this option is selected, the TMG ID Number (without any dataset number) also will be exported in a separate standard GEDCOM REFN tag as the tag following the GEDCOM INDI tag for that individual.

This option may be of use if the importing program does not use the GEDCOM INDI number as that individual’s ID number in the constructed dataset. Most importing programs will retain the GEDCOM REFN data, so this option at least should allow you to see the TMG ID number in such importing programs. In Step 7 of the Export Wizard you could specify that the TMG Reference field be exported also in a standard GEDCOM REFN tag. That REFN tag will be output in addition to the one specified for the TMG ID number.

6) Also in Step 5 you can select the character set to be used. TMG only provides the options of (ANSI, ANSEL, IBMPC) and defaults to ANSI which is the character set used by TMG’s underlying software.44 However, the GEDCOM 5.5 specification only allows three specific character sets (ANSEL, UNICODE, ASCII) and expects ANSEL.45 These character sets all differ in how they represent upper range special characters (the characters from 128 to 255). I have not fully tested whether such special characters will output differently within the exported file by specifying either of the other two character sets in TMG’s export. Unfortunately if the TMG export specifies ANSI, some software packages will not import such a file. All GEDCOM files specify the character set used to generate the file on an internal GEDCOM tag near the beginning of the file, e.g.:

Users have reported simply changing that name of the character set in that line in the file using a text editor to be one of the allowed GEDCOM values so that the file will import. It is not clear whether changing this character set name will affect how a specific importing software will deal with or change these upper range special characters. I recommend leaving the TMG export option as ANSI but changing the character set “name” in the resulting GEDCOM file to “ANSEL” if your importing software objects to ANSI. The user should review how the importing software now displays such upper range characters. See also the discussion of character sets when importing GEDCOM.

7) Set the GEDCOM line length to TMG’s maximum line length of 246. This will minimize data loss on created GEDCOM tags where the GEDCOM CONT/CONC continuation tags are not allowed or are limited to only one continuation line.

As of Version 9.04 a new Option in Step 5 of the GEDCOM export wizard was added:

As described in Version 9.04 and the final Version 9.05 TMG HELP, when this option is selected a number of additions are made to the GEDCOM export. Unless explicitly mentioned as part of this enhanced export option, all the conditions described above regarding what data is exported to a GEDCOM file are unchanged whether or not this option is selected. For example, for a TMG tag with two Principals to be exported as a GEDCOM family record, the two principals still must be married or must be the parents of one of more children (or both). And TMG Tag Types set to export as one of the above-listed non-existent GEDCOM tag names instead of as 1 EVEN 2 TYPE will still not export.

As described above, by default these two TMG tag types are set to export as the non-existent GEDCOM tag types of ADDR and PHON. If these tag types, or any custom tag types, are still set to export this way, this option will export the tags as the custom GEDCOM tag types of _ADDR and _PHON.

If the TMG Note tag type, or any custom tag type, is set to export as the GEDCOM tag type of NOTE, dates will be exported as a custom GEDCOM subtag under the NOTE tag:

TMG Name tag types should always have the GEDCOM export selection set to NAME, and with this enhanced option dates associated with these tags will be exported as the custom GEDCOM subtag:

For some import programs in order for this date data to be recognized as dates, these custom GEDCOM subtags for either the NOTE tags or NAME tags may need their tag names edited after export in the GEDCOM file to the standard GEDCOM tag name format by removing the leading underscore character in the custom tag name.

Sort dates are an advanced TMG feature. While they always exist within TMG, they can only be explictly entered/modified when in TMG’s Advanced (versus Beginner) edit mode. This enhanced export option will export these sort date values as a custom GEDCOM tag type following any tag’s standard DATE tag or any custom _DATE tag added by this enhanced export option.

A linkage to another individual who is a witness to this Principal’s TMG event tag, the witness’ TMG rolename, and any entered Witness memo specific to that witness now can be exported. The output will be a custom GEDCOM subtag _SHAR within that event’s GEDCOM structure with two subtags: a non-standard use of the standard GEDCOM ROLE subtag plus a standard NOTE subtag. The _SHAR tag will point to that witness using their INDI, the ROLE tag will contain the TMG rolename assigned to that witness in this tag, and the NOTE tag will contain their TMG witness memo. Since both the ROLE tag and the NOTE tag are subordinate to the custom _SHAR tag type, a custom use of these two subtags is implied. As an example, partial export output from a TMG Census event tag might be:

In the above example the numbers @I2@ and @I13@ point to the individuals with those GEDCOM INDI numbers in this GEDCOM file. As mentioned concerning ID numbers, they also are the TMG ID numbers of these individuals. As mentioned concerning NAME tags, there is no GEDCOM mechanism to assign a specific NAME tag to be associated with a specific event. Thus linkage of a particular NAME for this witness to this tag is also lost on export.

TMG surety has many more values and indications than defined in the standard GEDCOM QUAY feature. This enhanced export option will add a NOTE tag as part of the GEDCOM SOUR citation record following the GEDCOM QUAY tag. The NOTE data will contain all of the TMG surety data for the citation.

The five values will reflect the TMG surety values currently assigned to this citation. Consistent with TMG’s display of surety, periods will be used as filler values for blank surety values.

As described above, the Repository Place Detail is output by TMG on the GEDCOM ADDR tag. With this enhanced export option this data will be duplicated in an ADR1 tag as follows:

The main TMG tag memo text for the standard Caste, Descriptn (or Description), Education, Occupation, and Religion TMG tag types is output on the exported GEDCOM CAST, DSCR, EDUC, OCCU and RELI tag lines respectively. The GEDCOM specifications identify maximum allowed field lengths for the text on these tag lines for each of these tag types as:

TMG will export the entire memo text up to the maximum specified GEDCOM line length. Importing programs are within their rights to not allow longer text and/or to truncate any data in these fields to these maximum lengths. To prevent the text loss when the memo length exceeds 90 characters, with this enhanced export option selected for each of these five GEDCOM tag types the entire memo text will be moved to a NOTE tag subordinate to that tag and will not be truncated. Most importing programs will place the NOTE text in the event note field and the event description field for these imported tags will be empty. These event tags will require post-import cleanup; however, no text will be lost.

TMG doesn’t have a standard Property tag type. However if a user has customized a tag type to try to export this information to be converted later to the standard GEDCOM PROP tag type, that GEDCOM tag type allows up to 248 characters, and this provision to deal with lengthy memos will be used for that custom GEDCOM tag type.

The nature of imports changed with the new Import Wizard introduced in Version 5. Some GEDCOM files may be generated by other programs using the UTF-8 (unicode) character set or other character sets which TMG can’t import. The user will need to “pretend” to TMG that such a GEDCOM is an ANSI text file, which is the only character set TMG recognizes. Open the GEDCOM in a text editor (e.g Notepad) or a word processor (e.g. Word). Find the line specifying the character set used on export near the beginning of the file, e.g.:

Change the “something” value after “CHAR” to “ANSI” and save the file as a text file.46 Be sure to save only in text from the word processor and be sure that after saving, the file has a filetype of .GED. That file will then be able to be imported into TMG but some characters only expressible in unicode may be unknown characters. If your text editor or word processor can explicitly convert and save the file as ANSI or ANSEL, save the file in that new character set. The characters only expressible in unicode will now be converted, but the file will be able to be imported. See also the discussion of character sets when exporting GEDCOM.

All GEDCOM TITL and NAME tags are imported into a New project/dataset as TMG Name-Variation tags. See also the comments below about issues with name titles and prefixes. No TMG option is provided to change the import assignment of GEDCOM TITL and NAME tags, even with the Advanced Import Wizard. If a TMG custom Title-Event tag type in the Other group is desired for the GEDCOM TITL event, this will have to be recreated in the project/dataset from data lost on import. Regardless of the setting of the GEDCOM Import option “Read NPFX/GIVN/SURN/NSFX names” selection, a DATE subtag which is valid as part of a TITL tag to be merged with the Primary name is ignored. For these reasons it may be more useful to pre-process the GEDCOM file and change all TITL tag type names to a custom tag type name (e.g. _TITL) which would permit assigning these tags to a custom TMG event tag type. If unassigned it will still import and retain the date, but will become the generic TMG GEDCOM tag type with the importing GEDCOM tag type name and text inserted as part of that TMG tag’s memo.

On Import the GEDCOM namepart NPFX is imported into the TMG Title field of the Name tag. It is not imported into the Prefix field of the TMG Name tag as would be expected by the GEDCOM definition of NPFX. Further with the Export option “Name NPFX/NSFX” checked, the TMG Name/Title part is exported into a completely separate GEDCOM Event structure called TITL, which is not part of any GEDCOM NAME structure (for more details on Name titles see exporting GEDCOM Names above). Thus a TMG name that contains imported NPFX data will not Export that data back into NPFX because the data was imported into the TMG Name tag’s Title field instead of the Prefix field. Finally, there is a remaining bug which causes the SPFX surname prefix data to be skipped by TMG on import with a warning even when the Import option “Read NPFX/GIVN/SURN/NSFX names” is selected.

There are two possible NOTE structures within a GEDCOM file to be imported: a direct NOTE structure and a referenced NOTE structure. The GEDCOM 5.5 standard specifies that within any structure where a NOTE is permitted, either or both of the two NOTE structures may be used. TMG Import appears to handle a direct NOTE structure correctly except within a PLAC structure where the import warns it is skipped. TMG Import of a referenced NOTE structure produces a variety of results depending upon which GEDCOM structure the reference to the NOTE is within as documented in a remaining bug. If an import file contains referenced NOTE structures, it may be appropriate to preprocess the import file to duplicate such NOTE so the referenced structure may be removed.

Most standard GEDCOM tags will be assigned to the equivalent standard TMG tags upon import. But the Advanced import wizard should be used to deal with any generic GEDCOM event tags, as well as dealing with GEDCOM tags (whether main tags or tags subordinate to main tags) which are not recognized by TMG’s GenBridge. Examples of common unrecognized main or subordinate tags are: _AKA (which would be a name variation), _MARNM (which is the married name), ABBR (which is the name only using initials instead of a given name), etc., etc.

On Step 7 of the Advanced Wizard you can adjust most GEDCOM custom tag types or generic event tags to import them as custom tag types. However, there is no mechanism in TMG to pre-define TMG custom tag types to match specific importing GEDCOM tag types. These assignments must be done manually within the Wizard, which only permits naming the custom tag type and its tag group. The only TMG tag types available by default for assigning GEDCOM tags are the standard TMG tag types defined for a NEW project.

If a GEDCOM tag type or subordinate tag is unrecognized by TMG and not assigned to an appropriate TMG tag type, all such tag types will be imported as the single special TMG tag type of GEDCOM, and its data will be imported into the tag memo. In rare cases some unrecognized and unassigned GEDCOM tag types or subordinate tags may simply be lost and only reported in the error log. Next, every GEDCOM generic event “type” tag ( 1 EVEN 2 TYPE ) will import into the same TMG tag type of Event-Misc where the “type” name will be placed in the tag memo along with any other tag data. If these GEDCOM tag types are not assigned to appropriate TMG tag types as part of the import, the user will need to review and deal with them and their memo data after the import.

Normally the Advanced Wizard should be used to assign these GEDCOM tag types to an appropriate TMG tag type. An unassigned tag type can simply be assigned to either a standard or custom TMG tag type. For a generic event “type” the GEDCOM tag type first should be unassigned in the Advanced Wizard from Event-Misc and then assigned to an appropriate standard or custom TMG tag type.

If a particular type of GEDCOM tag is to be imported into a custom TMG tag type, as part of the Import the user must define the name of that custom TMG tag type and its TMG tag group. For example…

To (re)assign any generic GEDCOM tag which would be imported as an Event-Misc, after selecting the tag first click the [Unassign] button to unassign it from Event-Misc. To assign it as a custom tag type, click [Properties] and proceed as above. Otherwise simply assign it to a standard tag type.

For a generic tag type named “_AKA” to be reassigned to the standard “Name-Nick” tag type

Since the Import Wizard only permits naming the custom tag type and specifying its tag group, after the Import any further details of these custom tag types (roles, sentences, etc.) will have to be specified using the Tag Type Definition within the created project/dataset.

All GEDCOM FAMC relationship tags will be imported as TMG biological relationships even though the GEDCOM 5.5 definition of the FAMC tag structure allows the nature of that family relationship to be defined as one of four types using a PEDI qualifier tag (see also the details of exporting relationship tags above). If a PEDI qualifier tag exists, TMG will log it as unrecognized and ignore it. Any NOTE as part of a FAMC will not be imported as the memo for the relationship tag. Instead it will import as a separate TMG Note tag.

The GEDCOM 5.5 standard does define a method to allow a child to be linked to multiple family structures using multiple GEDCOM FAMC tags. TMG does import multiple FAMC relationships for a single individual, makes them all biological, and makes the first encountered FAMC relationship Primary.

All source records will be imported into a source using the primary/default Source Type. See also my discussion on the Book (Authored) source template. My testing has shown that if you import a GEDCOM file that has source records, the GEDCOM defined subtags of [TITL], [PUBL], [PAGE], and [TEXT] are automatically imported from these source records and prefill the four TMG source element groups Title, Publisher, Citation Detail, and Citation Memo respectively.

The GEDCOM specifications call for four Surety Values of 0 through 3. However, because there is no GEDCOM standard, some programs will export with other Surety Values, such as 1 through 4. In such cases, you would be tempted to enter those Surety Vales (e.g., 1234) with the Default Surety of 1 in Step 6. Unfortunately TMG will not accept the change. So you must leave the values of 0123 and the default of 0, which are the only surety values TMG will recognize. You should then review the surety values produced.

A number of programs auto associate the Windows “open” action on any file with the extension/type of “.ged” to their program (e.g. FTW). To avoid this issue, create a new action (say MyOpen) for this filetype, associate that in Windows to the program of your choice (say notepad, or TMG, or a GEDCOM reader), then make your new action the default action for this filetype. This way, when other programs (re)associate “open” with their program, it will have no effect since it is not the default action. Note that the exact steps necessary to do this will depend upon the version of Windows.

Endnotes
1. Export and Import of Sources and Source Types was added in Version 7. 2. While the Source Types window in the Tools menu will only show the source types for the dataset of the current focus person, the filter “Source Type is” in a List of Sources report will offer for selection the combined set of types from all datasets whether or not those other datasets are enabled in the Dataset Manager. 3. As deleting Source Types takes a while, you may wish to first “Initialize” the custom Source Types to “Lackey” because there are fewer to delete, then change back to Custom. 4. When importing Sources, there is no option provided to have one prefix for the Sources and a different one for the Source Types. 5. Export and Import of Tags and Tag Types was added in Version 8. 6. Last tested in Version 8.08 but should be tested in the final Version. Also verified by reviewing the TMG File Structure document provided by Wholly Genes for Version 9. 7. If you don’t select retaining all the sources themselves, you will also lose all your custom source types and elements. If all you desire are some of your customized Sources and/or Source Types, you could use the new feature introduced in Version 7 to export what you want from a customized dataset then import just those. Alternatively you could use that feature to separately export and then import both the Sources and Source Types. 8. If you only want some of the Repositories for selected Sources, you could use the new feature introduced in Version 7 to export only those Sources and their linked Repositories and then import just those. 9. If you only want some of your custom Tag Types, you could use the new feature introduced in Version 8 to export what you want from a customized dataset then import just those. 10. In 7.04, when you created a new dataset the Flags windows did not display the custom flags in the empty dataset. But they were copied, and displayed once a person was added to that empty dataset, or people were merged from another dataset. This was fixed in Version 8. 11. Note to self: Need to review and test whether I have extracted all the issues of interest to me from Terry’s Tips on this subject. 12. The behavior was first noticed in Version 7, the behavior was slightly modified in Version 8, and the behavior noted below is a remaining bug in the final Version. If two identically named tag types are in different tag groups, the duplicate tag types are imported/merged. But the tag type group of the tags in the incoming dataset will be changed to the tag type group of the existing same-named tag type in the receiving dataset. To demonstrate: create two datasets in the same project. Dataset “AD” has a custom tag called “MJH” in the Address group. Dataset “MG” has a custom tag, also called “MJH”, in the Marriage group. Note that the names are the same, but the tag groups are different. Merge dataset “AD” into dataset “MG”. In the combined “MG” dataset the “MJH” custom tag type that was merged-in has had its group changed from Address to Marriage, and there is now only one MJH tag type. Alternatively, merge dataset “MG” into dataset “AD”. In the combined “AD” dataset the “MJH” custom tag type that was merged-in has had its group changed from Marriage to Address, and there is now only one MJH tag type. 13. A remaining bug involves TMG confusing the Source Group of Source Element’s in different datasets in the same project when the custom Source Element names are identical but are in different groups. But the merge of two datasets with such same-named elements will be successful due to the modification of the incoming element’s name. 14. Prior to Version 6.0.9 if you changed the name of a custom flag, all people were set to the default value of that newly-named flag, i.e. flag name change was equivalent to delete/add. For those earlier versions changing the name of an existing flag was a two-step process. One had to define new unique flag names in the sending dataset and use the secondary output on a LOP report to set these new flags based on the old duplicate flag, then delete the duplicated flag prior to merging. 15. This changed behavior is reported as a bug in the list of outstanding bugs in the final Version 9.05. 16. Robin Lamacraft suggested this flag system on the TMG ListServ. 17. If the Flag name is the same, people who are imported by the merge will retain whatever Flag values they had, even if those values are not in the list of valid values for that Flag name in the receiving dataset. You will not be able to assign such a value until it is added to the valid list, but existing values will be retained. Verified with the Version 9 File Structure definitions that the single character value of a Flag is stored with the Person record, not as a pointer into the possible values in the Flag record. 18. Could also use the TMG Utility to export sources as web pages for comparisons. 19. Review and test the old options I used for Gedcom import for my old PAF2TMG process. 20. Need to test and verify this is still true in the final Version but do not believe this behavior has changed. 21. Need to extract the issues of interest to me from Terry’s Tips on this subject. 22. Based on Terry’s Tips from importing people from another database. 23. Need to test and update this with the issues of Name Styles for locations. 24. The following comment was in these notes, does not currently make sense to me, and may be left over from an option in an earlier version. This needs to be researched and tested. “The column ‘DefaultLabels’ appears not to be checked for match on merge, and a NO overrides a YES.” 25. Reported as of Version 6.12 but need to test in the final Version. 26. There was a bug in Version 6 where text marked [HID:][:HID] was exported. This was corrected in Version 7.04. 27. See below concerning split citations. 28. When the option “Name NPFX/NSFX” is not checked, inferring of GEDCOM name parts only occurs for export to GEDCOM 5.5, not for GEDCOM 4.0. In GEDCOM 4.0 the NameVar is output as an ALIA tag. In GEDCOM 5.5 the NameVar is output as a separate Name tag. I recommend selecting GEDCOM 5.5. 29. In addition to no field for Date, there is no field in GEDCOM to receive the TMG OtherName field or any sort name fields, regardless of the setting of the “Name NPFX/NSFX” option. They will be lost on Export. 30. An Exported TMG Name tag which had data in the Title field will not re-Import that Name/Title data into the Title field of an equivalent Name tag since upon Export it is no longer part of the Name structure (see also my notes about GEDCOM Import). 31. Both a TITL and a NAME tag will be exported even if the TMG Name-Var tag containing the title is specified to output to GEDCOM as TITL. 32. If the TMG Name-Var tag is specified to output to GEDCOM as TITL, two TITL tags will be created: one with only the title value on the TITL tag, and one with a full inferred name without the title on the TITL tag. 33. TMG might have chosen to export two identical Individual events, one for each Principal, as it does for GEDCOM tag types defined as Individual events. However, this is not done for two-Principal tags exporting as GEDCOM tag types which are defined as either expected or potential Family events. 34. If a specific GEDCOM TYPE text value is desired, the TMG tag type Name must be set to that value. 35. Although the GEDCOM FAMC and FAMS tags do define the option of a NOTE subtag, and that NOTE itself could have citations, none of this is generated by a TMG export. Tested in the final Version. 36. In TMG one parent could be biological and the other not. GEDCOM has no mechanism to show this. Even if both parents are set to the same TMG non-biological relationship tag type, TMG will not use the PEDI qualifier. Tested in the final Version. 37. Since TMG does not export a PEDI qualifier subtag, if it exported multiple relationships all these multiple FAMC tags would appear to be birth relationships, denoting the child had multiple sets of birth parents. Further, there is no GEDCOM mechanism to specify different qualifiers for each parent. 38. Added in Version 9.00. 39. See the TMG HELP topic “GEDCOM Export” for more details of the options affecting the creation of the QUAY tag. 40. Need to do further testing to identify exactly what exports and when from the TMG source templates. 41. Obtained from the final Version. The longer TMG tag names introduced in Version 8 are used in this table. 42. I know of no way to generate these two individual GEDCOM Attribute events in a GEDCOM export. The only option I can think of is to create custom TMG tag types using these names, specify them to output as GEDCOM EVEN/TYPE, and post process the GEDCOM file to change them to these GEDCOM tag types. 43. My custom tag types Cremation and DeathAssumeCrem are set to export as the standard CREM GEDCOM tag type. Likewise my custom BaptAdult tag type is set to export as the standard CHRA GEDCOM tag type. 44. The underlying software is MicroSoft FoxPro, whose documentation states is based on the ANSI character set which is why the TMG software uses this term. This is not an official name of a standard character set, and actually refers to a character set defined by MicroSoft called “Windows-1252”. 45. ANSEL is a character set which defined some of the characters in the range 128-255 specifically for use in bibliographies. GEDCOM adopted it and defined some additional characters in this upper range. Unfortunately even though some of these characters exist in the other character sets, the assignment of these characters in ANSEL do not match any of the other character sets (Unicode, ANSI, ASCII, IBMPC). 46. TMG’s underlying software is MicroSoft FoxPro, whose documentation states is based on the ANSI character set which is why the TMG software uses this term. This is not an official name of a standard character set, and actually refers to a character set defined by MicroSoft called “Windows-1252”.

Endnotes

1. Export and Import of Sources and Source Types was added in Version 7.

2. While the Source Types window in the Tools menu will only show the source types for the dataset of the current focus person, the filter “Source Type is” in a List of Sources report will offer for selection the combined set of types from all datasets whether or not those other datasets are enabled in the Dataset Manager.

3. As deleting Source Types takes a while, you may wish to first “Initialize” the custom Source Types to “Lackey” because there are fewer to delete, then change back to Custom.

4. When importing Sources, there is no option provided to have one prefix for the Sources and a different one for the Source Types.

5. Export and Import of Tags and Tag Types was added in Version 8.

6. Last tested in Version 8.08 but should be tested in the final Version. Also verified by reviewing the TMG File Structure document provided by Wholly Genes for Version 9.

7. If you don’t select retaining all the sources themselves, you will also lose all your custom source types and elements. If all you desire are some of your customized Sources and/or Source Types, you could use the new feature introduced in Version 7 to export what you want from a customized dataset then import just those. Alternatively you could use that feature to separately export and then import both the Sources and Source Types.

8. If you only want some of the Repositories for selected Sources, you could use the new feature introduced in Version 7 to export only those Sources and their linked Repositories and then import just those.

9. If you only want some of your custom Tag Types, you could use the new feature introduced in Version 8 to export what you want from a customized dataset then import just those.

10. In 7.04, when you created a new dataset the Flags windows did not display the custom flags in the empty dataset. But they were copied, and displayed once a person was added to that empty dataset, or people were merged from another dataset. This was fixed in Version 8.

11. Note to self: Need to review and test whether I have extracted all the issues of interest to me from Terry’s Tips on this subject.

12. The behavior was first noticed in Version 7, the behavior was slightly modified in Version 8, and the behavior noted below is a remaining bug in the final Version. If two identically named tag types are in different tag groups, the duplicate tag types are imported/merged. But the tag type group of the tags in the incoming dataset will be changed to the tag type group of the existing same-named tag type in the receiving dataset.

To demonstrate: create two datasets in the same project. Dataset “AD” has a custom tag called “MJH” in the Address group. Dataset “MG” has a custom tag, also called “MJH”, in the Marriage group. Note that the names are the same, but the tag groups are different. Merge dataset “AD” into dataset “MG”. In the combined “MG” dataset the “MJH” custom tag type that was merged-in has had its group changed from Address to Marriage, and there is now only one MJH tag type.

Alternatively, merge dataset “MG” into dataset “AD”. In the combined “AD” dataset the “MJH” custom tag type that was merged-in has had its group changed from Marriage to Address, and there is now only one MJH tag type.

13. A remaining bug involves TMG confusing the Source Group of Source Element’s in different datasets in the same project when the custom Source Element names are identical but are in different groups. But the merge of two datasets with such same-named elements will be successful due to the modification of the incoming element’s name.

14. Prior to Version 6.0.9 if you changed the name of a custom flag, all people were set to the default value of that newly-named flag, i.e. flag name change was equivalent to delete/add. For those earlier versions changing the name of an existing flag was a two-step process. One had to define new unique flag names in the sending dataset and use the secondary output on a LOP report to set these new flags based on the old duplicate flag, then delete the duplicated flag prior to merging.

15. This changed behavior is reported as a bug in the list of outstanding bugs in the final Version 9.05.

16. Robin Lamacraft suggested this flag system on the TMG ListServ.

17. If the Flag name is the same, people who are imported by the merge will retain whatever Flag values they had, even if those values are not in the list of valid values for that Flag name in the receiving dataset. You will not be able to assign such a value until it is added to the valid list, but existing values will be retained. Verified with the Version 9 File Structure definitions that the single character value of a Flag is stored with the Person record, not as a pointer into the possible values in the Flag record.

18. Could also use the TMG Utility to export sources as web pages for comparisons.

19. Review and test the old options I used for Gedcom import for my old PAF2TMG process.

20. Need to test and verify this is still true in the final Version but do not believe this behavior has changed.

21. Need to extract the issues of interest to me from Terry’s Tips on this subject.

22. Based on Terry’s Tips from importing people from another database.

23. Need to test and update this with the issues of Name Styles for locations.

24. The following comment was in these notes, does not currently make sense to me, and may be left over from an option in an earlier version. This needs to be researched and tested. “The column ‘DefaultLabels’ appears not to be checked for match on merge, and a NO overrides a YES.”

25. Reported as of Version 6.12 but need to test in the final Version.

26. There was a bug in Version 6 where text marked [HID:][:HID] was exported. This was corrected in Version 7.04.

27. See below concerning split citations.

28. When the option “Name NPFX/NSFX” is not checked, inferring of GEDCOM name parts only occurs for export to GEDCOM 5.5, not for GEDCOM 4.0. In GEDCOM 4.0 the NameVar is output as an ALIA tag. In GEDCOM 5.5 the NameVar is output as a separate Name tag. I recommend selecting GEDCOM 5.5.

29. In addition to no field for Date, there is no field in GEDCOM to receive the TMG OtherName field or any sort name fields, regardless of the setting of the “Name NPFX/NSFX” option. They will be lost on Export.

30. An Exported TMG Name tag which had data in the Title field will not re-Import that Name/Title data into the Title field of an equivalent Name tag since upon Export it is no longer part of the Name structure (see also my notes about GEDCOM Import).

31. Both a TITL and a NAME tag will be exported even if the TMG Name-Var tag containing the title is specified to output to GEDCOM as TITL.

32. If the TMG Name-Var tag is specified to output to GEDCOM as TITL, two TITL tags will be created: one with only the title value on the TITL tag, and one with a full inferred name without the title on the TITL tag.

33. TMG might have chosen to export two identical Individual events, one for each Principal, as it does for GEDCOM tag types defined as Individual events. However, this is not done for two-Principal tags exporting as GEDCOM tag types which are defined as either expected or potential Family events.

34. If a specific GEDCOM TYPE text value is desired, the TMG tag type Name must be set to that value.

35. Although the GEDCOM FAMC and FAMS tags do define the option of a NOTE subtag, and that NOTE itself could have citations, none of this is generated by a TMG export. Tested in the final Version.

36. In TMG one parent could be biological and the other not. GEDCOM has no mechanism to show this. Even if both parents are set to the same TMG non-biological relationship tag type, TMG will not use the PEDI qualifier. Tested in the final Version.

37. Since TMG does not export a PEDI qualifier subtag, if it exported multiple relationships all these multiple FAMC tags would appear to be birth relationships, denoting the child had multiple sets of birth parents. Further, there is no GEDCOM mechanism to specify different qualifiers for each parent.

38. Added in Version 9.00.

39. See the TMG HELP topic “GEDCOM Export” for more details of the options affecting the creation of the QUAY tag.

40. Need to do further testing to identify exactly what exports and when from the TMG source templates.

41. Obtained from the final Version. The longer TMG tag names introduced in Version 8 are used in this table.

42. I know of no way to generate these two individual GEDCOM Attribute events in a GEDCOM export. The only option I can think of is to create custom TMG tag types using these names, specify them to output as GEDCOM EVEN/TYPE, and post process the GEDCOM file to change them to these GEDCOM tag types.

43. My custom tag types Cremation and DeathAssumeCrem are set to export as the standard CREM GEDCOM tag type. Likewise my custom BaptAdult tag type is set to export as the standard CHRA GEDCOM tag type.

44. The underlying software is MicroSoft FoxPro, whose documentation states is based on the ANSI character set which is why the TMG software uses this term. This is not an official name of a standard character set, and actually refers to a character set defined by MicroSoft called “Windows-1252”.

45. ANSEL is a character set which defined some of the characters in the range 128-255 specifically for use in bibliographies. GEDCOM adopted it and defined some additional characters in this upper range. Unfortunately even though some of these characters exist in the other character sets, the assignment of these characters in ANSEL do not match any of the other character sets (Unicode, ANSI, ASCII, IBMPC).

46. TMG’s underlying software is MicroSoft FoxPro, whose documentation states is based on the ANSI character set which is why the TMG software uses this term. This is not an official name of a standard character set, and actually refers to a character set defined by MicroSoft called “Windows-1252”.

I am not affiliated in any way with TMG™, its company Wholly Genes, Inc., or its primary author Bob Velke, nor with John Cardinal, author of several TMG after-market programs. I am simply a satisfied user of these software packages and have constructed these documents to aid me in their use.

If others find these documents useful, so much the better. I do not warrant in any way that they are accurate or useful, and any use of them is at the user’s own risk.

These documents were composed with Adobe^® Framemaker 2019^® using its hyperlink and "Save as HTML" conversion features.

	Principal1…	ID #	<> Does not equal	0	AND
	Principal2…	ID #	<> Does not equal	0	END