Which dictionary do I use if I have multiple versions of Microsoft Dynamics GP?
If you are a Dexterity developer with many alternate Dynamics GP forms in your development dictionary, e.g., your development dictionary is Dynamics GP2013 RTM and the Dynamics GP client application dictionary is GP2013 SP1, which dictionary do you use?
If the dictionary originally derived from an earlier build of the Dynamics GP dictionary “Dynamics.dic” within the same major version, this is not an issue. However, at times, form procedure and function signatures change with service packs, releases, or hotfixes. Meaning, any dictionary references to those scripts on the alternate forms will raise errors at runtime, even though they still compile error-free and generate proper chunk files. Additionally, if you remove security for a user to the alternate form and try the same process that generated an error when security was granted, no errors are generated and the process continues as expected.
Here is an example:
Current Dynamics GP client version: 2013 SP1
Dexterity development dictionary version: 2013 RTM
Alternate resource: POP_Receivings_Entry
Issue: Users have access to the alternate form and not the “base” form and receive errors when pressing the Auto Rcv button
What’s happening?
The errors are being generated because security is granted to the alternate POP_Receivings_Entry form that is present in the custom dictionary, which contains the definition from the RTM build, while the resources around that dictionary are all at the SP1 level. When security is removed, the POP_Receivings_Entry form present in the core application dictionary is invoked, which contains the “correct” definition and script signatures.
The documented way to resolve this issue is to fetch all custom and alternate resources from source control into the correct Dynamics.dic file, recompile, and then recreate the window mods that resulted in the alternate forms. If there are only a few alternate resources and the changes are not significant, this is the best and cleanest option. However, if there are several alternate forms or the form changes are non-trivial, then Dexterity Utilities can be used to import the current stock resources into the development dictionary. Once that process is complete, the Dexterity IDE can be used to recreate the form modifications in a targeted manner, resulting in less ramp-up time and rework.
How to fix:
- Copy and rename the current development dictionary so that there is a backup. In this example, the development dictionary is named Dynamics.dev.dic and the backup dictionary is Dynamics.dev.orig.dic.
- Open Dexterity Utilities for the current version of Dexterity.
- Go to File > Open Source Dictionary and select the current unmodified Dynamics client dictionary from the GP Dynamics client folder.
- Open the development dictionary as the destination dictionary (File > Open Destination Dictionary).
- Select Transfer > Dictionary Module from the toolbar.
- Select the correct Series and Module Type, then select the appropriate resource. In the provided example, the Series would be Purchasing, the Module Type would be Forms, and the Dictionary Module is [Form] POP_Receivings_Entry. (You can select multiple modules within reach series/type.)
- Click the Transfer button and continue when the system prompts you to overwrite the module in the destination dictionary.
- If there are additional modules that need to be transferred, continue with Step 6. Otherwise, proceed to Step 9.
- Click Close, close the source and destination dictionaries, and then close Utilities.
- Open the “new” development dictionary and recreate the form modifications.
That’s it! Recompile the development dictionary and note or correct any errors. Since there is a backup of the original development dictionary prior to using the Transfer feature in Utilities, you will have peace-of-mind in knowing that you can always roll back.
If you have questions or need some assistance, visit our support page for more help.
