Unknown identifier 'DYNAMICS' or other Constant with GP 2010 SP1
Recently, we have been seeing some weird errors where previously working code fails to compile with an Unknown Identifier error referring to a constant in the core Dynamics.dic dictionary.
I came across this issue myself when preparing for the recent Technical Conference, see my post: Microsoft Dynamics GP Technical Conference 2011 - Day minus 2.
The errors occur for Microsoft Dynamics GP 2010 Service Pack 1 or later when using a Country setting other than United States. The error messages shown when compiling a script will be in the form:
Unknown identifier 'DYNAMICS'.
Unknown identifier 'SEQUENCE_LINE'.
You might also find these errors occurring at runtime if your customisation is using the execute() function to compile and run pass through sanScript code at runtime.
Further analysis shows that the US DYNAMICS.DIC for SP1 has 7284 constants when an Australian (or other non-US) DYNAMICS.DIC for SP1 only contains 5118 constants. Some 2166 constants have been lost from the dictionary.
It seems the problem is caused when the XXERR.CNK language chunk is combined with the standard US DYNAMICS.DIC, for some reason it is corrupting the dictionary and causing the constants to be lost.
This will not break the code already compiled in the the DYNAMICS.DIC as constants are only evaluated at compile time. So all the core code will continue to work fine even if the dictionary is missing constants.
The problem occurs for international 3rd party developers who need to compile against a non-US core DYNAMICS.DIC while developing, or for code which is compiled at runtime using execute()running on an international (non-US) system. This could also affect passthrough code from Visual Basic for Applications (VBA) or Visual Studio Tools, if that code attempts to reference one of the missing constants.
Some possible work around solutions for this issue include (Option 4 is the best solution):
- Develop your code using a US DYNAMICS.DIC from a Microsoft Dynamics GP 2010 SP1 installation. The chunk will work fine on an international install.
- Develop your code using your country's DYNAMICS.DIC from a Microsoft Dynamics GP 2010 RTM installation and use the SkipVersionChecks=TRUE DEX.INI setting. This is fine as long as you don't have alternate forms and reports of resources that have changed in SP1 or reference functions, procedures or other resources which have changed in SP1.
- Change your code to use the values specified in the constants. This is not recommended as you will lose all the benefits offered by constants.
- Before starting, add MainProduct=TRUE into your Dex.ini. Then export the constants from a US Service Pack 1 DYNAMICS.DIC and import them into your country's Service Pack 1 DYNAMICS.DIC. I have already exported the constants and the export file is attached to the bottom of this post. However, the importing process will take a number of hours (2-3) to run, Dexterity will say "Converting the textual resources to their dictionary formats. Please be patient. This may take several minutes.". Dexterity will also say that it is "(Not Responding)", but it is running and just needs to be left to finish. Be sure to remove MainProduct=TRUE from your Dex.ini afterwards.
NOTE: If you use option 4 to fix your DYNAMICS.DIC in your live environment, you can then start using this dictionary as your base development dictionary. To fix Forms.dic and Reports.dic, you will need to export all your customizations as packages using Customization Maintenance, then rename the forms.dic and reports.dic and re-import the packages. Changes to base resources such as formats, strings, messages, etc. will need to be remade manually (or using a previously recorded macro).
The latest French and Spanish tax release hotfixes fix those versions, but we are still waiting on a fix to be released for International English and will update this post once one is available.
David
30-Mar-2011: Added Dex.ini setting change for option 4 to ensure the added constants have a resource ID lower than 22,000. This will prevent a clash with constants added by the developer.
30-Mar-2011: Updated attached file to only contain the missing constants. This should speed up the import process.
CR 8192, PR 60641