A lot of people have been using Microsoft Dynamics GP (formerly Microsoft Business Solutions, formerly Great Plains) for many years, so you’ve already encountered corrupt reports dictionaries. You know what to add to the Dex.ini in order to create troubleshooting logs. You can say “been there, done that” when the error dialog box pops up with an ODBC or SQL error. You may even remember hearing “Welcome to Dynamics” when you logged in (it’s been awhile, but I do recall having a customer that wanted to change the voice so it sounded like Antonio Banderas instead of that pleasant woman…)
But for those of you who are new to the Dynamics GP world, this is an introduction to underlying architecture which I hope will explain some of the issues reported every day and help you resolve them. I like to think of it as the Dynamics rendition of the good, the bad, and the ugly: The DIC, the EXE, and the SET.
You thought they were reference books used to look up word definitions, but no: in Dynamics world, dictionaries are application code. They contain the logic that tells Dynamics what to do when you click a button or open a window. The Dynamics.dic is the main application dictionary and resides in the Dynamics program folder. Other files with the .dic extension are for add-on products and products that have been acquired by Microsoft over the years but not incorporated into the main dictionary. For example, FAM.dic contains fixed assets code, HR.dic contains Human Resources code, etc. Some of the names are not easily matched to a product, so if you have questions about which dictionary maps to which product, you can find out using the Dynamics.SET file, which references all the active dictionaries in your system.
The important thing to remember about these main dictionaries is that they only change if the product is upgraded or a service pack is applied. The main dictionary contains every standard report and form (window) for the application or add-on product.
In addition to the main product dictionaries, you may have a reports and forms dictionary associated with each product. These .DIC files usually have a similar name to the main dictionary and are preceded or followed by an R or F, depending on the type of dictionary it is. The Reports.DIC and Forms.DIC are associated with the Dynamics.DIC and by default reside in the Dynamics program folder under the Data subfolder.
Common practice in a multi-user environment is to save these modified dictionaries in a network shared location which is backed up on a regular basis.
Reports and Forms dictionaries contain any modified reports or forms (windows) that have been created for the standard Dynamics GP modules, such as general ledger, payables, receivables, or inventory. Similarly, if you have any modified Fixed Asset reports or forms, you would see a R309.DIC or a F309.DIC in the network share.
Whenever you have modified reports or forms, it is essential that these dictionaries are backed up regularly. Each time the report is modifed or accessed by a user, there is potential for corrupting the contents. If this should occur, a corrupt report can cause Dynamics world to become inaccessible to all users until the file is restored or removed from the environment. If you don’t have a backup and the reports.dic becomes corrupted, you can always revert back to the standard, unmodified reports in the Dynamics.DIC. See below for how to manage this.
Dynamics.exe is the actual executable that runs Dynamics GP, but if you’ve ever double-clicked it, you’ve been in for a surprise because it just opens a Dexterity runtime window with a File menu where you can select a launch file (see below).
So when you double-click the Dynamics icon on your desktop or you select it from Start>>Programs>>Microsoft Dynamics>>GP10, what you are doing is launching the application (exe) by referencing the launch file (set). If you look at the shortcut properties for the Dynamics icon, you will notice this reference: “C:\Program Files\Microsoft Dynamics\GP\Dynamics.exe” Dynamics.set.
When combined with the Dynamics.set file, Dynamics.exe takes us to Dynamics world.
The launch file (Dynamics.set) resides in the Dynamics program folder as well, but it can be placed elsewhere, and some environments require multiple SET files for various purposes, such as providing distinct sets of modified reports for different company databases or disabling certain products for a particular user. This is accomplished by simply creating the distinct SET file (editing the main one and saving it with a new file name is the easiest way) and then creating a shortcut that references the new SET file. The SET file can be named anything: it doesn’t have to be called Dynamics.set.
As you can see, the launch file is a critical player in making Dynamics world a great place to hang out. Here is an example of a SET file.
The first line of the file tells you how many products are installed, including the Dynamics product itself, which is product zero. It is very important that the correct number of products is at the top of the file because if someone edits the launch file and removes a product but does not adjust this number, the user will get a memory allocation error and Dynamics world will be inaccessible.
The next section of the file contains the list of all dictionaries loaded, along with their Microsoft-assigned product number. As you can see, the number comes first, then the product. So product zero is Microsoft Dynamics GP, product 105 is Integration Manager, etc. The products don’t have to be listed in any particular order, but there are caveats:
(1) product zero should always be listed first, (2) the order of the products MUST match the order of the product dictionary paths in the bottom section of the file, and (3) Windows should always be listed after the final product.
Which brings us to the third and final section of the file. This section references the paths for each product listed in section two and it also allows the flexibility of referencing reports and forms dictionaries for each product.It is imperative that the product paths listed in this section match EXACTLY in sequence the list of products from section two. There should be three lines for each product, one for the product dictionary, one for the reports dictionary, and one for the forms dictionary. If any of these are missing Dynamics GP will not function properly. For example, the first three lines should always be valid paths to the Dynamics.DIC, Reports.DIC, and Forms.DIC.
Note: the reports and forms dictionaries for each product may not exist, but the paths must be defined in the SET file. Reports and forms dictionaries are not created unless and until a user modifies an associated report or form, so the absence of a reports or forms dictionary just means there are no modified versions of any of these items. Dynamics still needs the paths where those dictionaries would reside if they did exist.
If your environment has modified reports and/or forms stored in a network share, the paths to those dictionaries will need to be defined in each user’s Dynamics.SET file. This step should be part of a standard client installation to ensure that all users have an enjoyable time in Dynamics world.
To summarize, this is just an introduction to the good, the DIC, the EXE, and the SET file. If you would like in-depth reading, please consult the System Administrator’s guide for Microsoft Dynamics GP.