Another thread on the GPUG forum prompted me to write this article. It is one that I have been meaning to write for a while as this is not the first time I have seen complaints that a Dex.ini setting does not work or is not behaving as expected.
This article explains the changes made in the recent versions of Microsoft Dynamics GP and how they could be causing the behaviour you are seeing.
The change in question is the addition of Per User Dex.ini settings for Microsoft Dynamics GP 2013 onwards. This allows dex.ini settings to be associated with a user rather than the workstation. The settings will follow the user regardless of where they login. This is really handy for settings like window positions as they now stay with the user wherever they are.
How it works
The System Level Dex.ini file is usually stored in the Data folder underneath the Microsoft Dynamics GP application folder.
Before the Per User Dex.ini settings feature was available, some systems were set up on Terminal Servers to fake user level settings by changing the shortcut to launch GP to include the path to a Dex.ini file in the user’s home folder, for example:
From version 12 onwards, this is no longer needed as the system supports this functionality itself. The change was primarily made to help with Web Client installations to ensure that the settings followed the user regardless of which runtime instance they connected to.
The User Level Dex.ini file is enabled with the following setting in the System Level Dex.ini file:
Once enabled, during login the User level settings are copied from a table into a temporary .ini file in the %TEMP% folder for the current user session. When the user logs out, the settings are written back to the table so they can be stored between sessions.
The Dexterity commands to read Dex.ini settings will (by default) read from the user level dex.ini file first and if they cannot find the setting will then read from the system level dex.ini file. So if a setting exists in the user level dex.ini file it takes precedence over the system level dex.ini file. This means that changes made to the system level dex.ini file may not work as expected. You can tell the Dexterity command to specifically read from the user or system level, but all the existing code will have this default behaviour.
The Dexterity commands to write Dex.ini settings will (by default) write to the user level dex.ini file, if you want the setting to go to the system level dex.ini file it must be specified in the code.
If you have GP Power Tools installed, you can use the Dex.ini Configuration window to change settings automatically on login for both user and system/global level dex.ini files. This works for all users and workstations as long as GP Power Tools is installed on all workstations (as recommended).
And in the latest builds you can use the button on the bottom left of the window to access a Dex.ini Settings editor to change settings, but only for the current workstation and current user.
If you don’t have GP Power Tools, you can manually use SQL Server scripts to change the Dex.ini settings for a user.
NOTE: Make sure they are logged out first, otherwise any changes to make to the table are lost when they log out and the temporary file is copied back to the table.
Using the script examples below you can look for and change settings in the syUserDexIniSettings (SY01405) User-Specific Dex.ini Settings table in the system (usually DYNAMICS) database.
select * from SY01405 where IniKeyName = 'NoPrintDialogs' --update SY01405 set IniKeyValue = 'TRUE' where IniKeyName = 'NoPrintDialogs' and USERID = 'sa'
I hope this information is useful.
This article was originally posted on http://www.winthropdc.com/blog.