Hybrid - Clearing the Last User on a Terminal Server Example

Microsoft Dynamics GP remembers the last user to use the application and defaults the User ID into the login window next time the application is loaded.  This is useful when only a single user uses the specific workstation install.  In a Terminal Server or Citrix environment, multiple users use a single workstation install and so it would preferable if the User ID was left blank when the application launches.

The User ID is stored as the SQLLastUser=XXXXX setting in the Dex.ini file, where the XXXXX represents the last User ID.  One method to ensure that this setting remained blank was to change the Dex.ini file to be read only.  However, this can have negative side effects on application code that expects to be able to write to the Dex.ini file.  Also changes in v10.0 for Vista Compatibility mean that a read only Dex.ini file will not be used by Microsoft Dynamics GP.

Another method could be to use Visual Basic for Applications (VBA) to clear the Dex.ini setting after each login.

This example uses a Toolbar package as explained in in the post VBA - Running VBA scripts after Login or before Logout Example. This package allows us to run our script after login is completed.  We then use the Continuum Integration Library to execute Dexterity sanScript commands to update the dex.ini to clear the SQLLastUser setting. 

NOTE: This customisation uses a method of executing Dexterity sanScript code from VBA which is unsupported by Microsoft.

Example code for v8.0, v9.0 & v10.0 is attached at the bottom of the article.

Please see the "Installation Instructions.txt" file in each version's archive for more information.

11-Aug-2008: The functionality to clear the Dex.ini setting is also available as part of the Omni Login module of the Omni Tools suite from Rockton Software.

Ref: Internal KB 949617

Remove SQLLastUser Dex.ini setting.zip

Comments

• Anonymous
  July 28, 2008
  PingBack from http://blogs.msdn.com/developingfordynamicsgp/pages/modifier-vba-samples.aspx

• Anonymous
  August 07, 2008
  This is an excellent article, which I was looking out for quite some time. :-) Thanks David

• Anonymous
  March 19, 2012
  David - Is there a way to remove this coding once a user has implemented the wondrous Support Debugging Tool?

• Anonymous
  March 19, 2012
  Jarrid, Not easily as the Toolbar isn't exposed since 9.0. However if you have no windows open, does Tools | Remove Current window from VBA enable and work to remove the code? That used to be how you added/removed it when the Toolbar was visible. If that doesn't do it, then you can delete the Dynamics.vba file but that will remove all other Dynamics VBA customizations. So you could expot all your Dynamics (other apps are ok) customizatons, then rename the Dynamics.vba, then import them back in again (except for the Toolbar one for this). Lastly, you could just go into the VBA editor and find the Toolbar form.  Set the EventMode from "emOriginalOnly" to "emNever" and now the VBA code will still be there but won't run.

• Anonymous
  March 19, 2012
  Patrick  - Those sound like very viable options. I will try each when I am back from Convergence 2012 - It's a completely virtual environment, so I should be able to try each without too much repercussion. Thank you for the help, and I will respond with the results.