Personalizing Your TMG Installation
(Note: This was written for TMG v7.x)

Do you have more than one TMG project?  If you do, you may have experienced odd situations while working with one of those projects.  These are rare nuisances of the type that cause you to think ‘what is going on here?’  Often, the oddity causes you to think that you may need to re-index your project.  Later (hours or days), something else gives you pause again.  These weird situations may be due to needing to have more separation between projects.

An example of this odd situation is when you print a report and find that some of the persons or families that you expected in the report either aren’t there or others are included when they should not be there.  Another example is when you have Accents turned on and certain ones seem odd.   Then there is the Picklist or Project Explorer when it/they are filtered and turn out to include persons that you don’t expect or not include those you expect.

First, let me re-assure you.  The data in your projects is safe.  The problem is not one where the data has been corrupted.  Instead, you have caused TMG to perform these odd situations by telling it to use the wrong file for the operation without realizing it.  This usually occurs when you have projects that are similar and may even have some of the same persons or Flags or other similarities.  You may have worked in one project for a good bit doing a lot of work.  Then you switch to another project.  Suppose you had created an Accent in the other project that you think may work in this current project.  Accents, filters, Report Definitions, Timelines, Exhibits, and other files can often be used in other projects.  BUT, you do need to be careful that the definition given that files is completely compatible with your current project.  For example, an Accent designed for project A may be designed around a certain Flag which has the same name in project B and which uses the Flag slightly differently.  Thus using the Accent in project B may give odd results.

As noted, the cause of the problem is telling TMG to using a file when that file should not be used.  So how do you prevent this?  Well, obviously, by remembering that you should not use a certain file with the “wrong” project.  This is a reasonable measure if you only have a few projects and only a few of these files.  But if you have many projects and/or many files this does not work well.

The problem is usually attributed to the way TMG is installed.  Many users install the program using the default method or by using a slight variation.  Most users never have a problem.  Occasionally, a user will have a problem, look in TMG Help or in one of the on-line forums and resolve the situation on their own without anyone else knowing that a problem occurred.  Other users may not realize that their problem is one of installation. 

TMG’s default installation works very well for most users – especially those with just one project or very few projects which are quite different.  And, let’s face it; the problem is rare as very, very few reports are made of these situations. 

A big change to the default installation of TMG was required by the advent of Windows Vista and continued with Windows 7.  Prior to Windows Vista, many programs stored certain files within the program’s installation folder.  These might have been data files or just configuration files that could be changed by the program as the user wished.  This changed with Vista when restrictions were placed on the program installations and prevented data or configuration files from being installed in the program’s installation area.

For this reason, TMG’s current installation method was developed.  At the same time, it was recognized that many users might desire to install the program in a more custom manner.  So, a provision was included for those users that preferred to install TMG as they wished.

The default TMG installation method provides for TMG files to be stored in one of three areas.  These three file storage areas are:

• Shared Program Data (SPD) Files – files that are expected to have few or no changes.

• User Program Data (UPD) Files – files the user may often change.

• User Data (UD) Files – project and project-related files that change daily.

For those users wishing to install TMG in a custom manner, TMG provides for that while still retaining these three areas. 

One reason that a custom installation might be desired is that the default installation is designed for a single user and the custom installation would provide for multiple users – either separately (for security) or together (when security is not a problem).  This might include the situation where a professional genealogist wishes to have client project separate from personal projects.  Or a husband and wife wish to have a separate project for each of their ancestors.  Another reason is that the user may simply prefer TMG be installed on a different drive. For these custom installations, a Data_Paths.txt file is created by the user and placed in the TMG Program Files folder as described in TMG Help under the Customizing Data File Storage topic.

This article is intended to expand on the TMG installation not by changing any of the various installation methods.  Instead, its suggestions do not come into play until after TMG has been installed and initially opened.  Further, the only changes here are to the UD files and how they are stored and used.

A representation of the default installation of the User Data area is shown below. 

Accent and filter files are stored in the same folder as a project’s data files.  So, to prevent conflicts in projects from Accents and filters, many users create sub-folders within the Projects folder for each project that they have.  The diagram below gives an example of this where three sub-folders for the SAMPLE, SMITH and JONES projects are created within the Projects folders. Thus, any Accents or filters created for one project would not provide conflict in another project.

While this will prevent most conflicts, there could still be other conflicts.  For example, what would happen if two External Exhibits had the same filename?  Of course, this would never happen as no one would name two image files of the family picnic on July 4^th with the same name (July 4^th 1948 Picnic) even though the images are for two different families.  If the images are used in the same project, there would definitely be a problem unless the user took pains to alter the filename of one of the Exhibits.  But if the Exhibits are used in two different projects, the user may not realize the conflict until later – and possibly after one Exhibit has overwritten the other.

For this reason, some user may wish further separation of other User Data (UD) files that might include Exhibits, Configuration Files, Repeat_Files, etc. in a similar way to separating projects as above.  This is easily done by adding sub-folders to the appropriate UD folders corresponding to the project sub-folders in the UD Projects folder as above.  Below is an example of an installation with just the Exhibits folders “sub-divided” like the Projects folder.

“Sub-dividing” all the other folders may be done if the user wishes.  However, this may or may not be needed for some folders.  For example, the Timelines folder would contain the Timelines install by TMG and are designed for use by all projects.  Of course, the user may wish to customize one or more of the furnished Timelines for each project they have.  Or, more likely, the user may create Custom Timelines for each project.  If the Custom Timelines are given the same names then they need separation to prevent conflict with another project.

Similarly, the Backup, Export, and Report_output folders probably would probably not have sub-folders as any files placed in those folders would be unique enough to separate them.  However, the user may have reason to sub-divide these folders.

One final note is that when the user creates the sub-folders in any folder for a project then the user must insure the correct paths for any of these sub-folders that you created are entered in the Advanced tab of Preferences for that project.  

Another method to insure project separation would be to start with Choice B above and create each of the other folders (or at least the ones that you want) in each of the Projects folder project sub-folders.  For example, each project sub-folder might have: an Exhibits sub-folder, a Repeat_files sub-folder, etc.  Again, certain of the folders (i.e., Backups, Timelines, etc.) may remain.  And, again, be sure to adjust Preferences=>Advanced paths as appropriate for each project.

There are probably other ways that you can insure projects are separate from each other.  The above are just two.  The first just seems to me to be the easiest to create/use and remains the closest to the default installation. 

Return to the TMG Tips Homepage

Last revised: