Citrix – TS

A remove range operation on table ‘SY_Current_Activity’ failed accessing SQL data


You’ve probably encounter this error message on rare occasions in Dynamics GP, but be prepared for seing an increase with GP 2015 & up.

Recently I was working on a case with a customer that upgraded last fall (2016) from GP 2010 to GP 2015, and ever since the upgrade, the users who access GP over Citrix exclusively (no local GP clients) had randomly issues with pop-ups denying them access to some of the 50 GP companies.. The corporation has office mainly on the east-coast and also over in Asia, thus making the maintenance more difficult with the 13-hours timeshift, as the system is busy most of the 24h in a day.


However, as they also use tons of 3rd-party ISV products and some customization, it was hard to pinpoint the culprit / faulty module. At some point we thought that it was the “inactivity” timer of the Rockton Toolbox that was causing this, but it made no sense to me, especially as the companies were not in the user’s access list.. Disabling the feature in RSTB was only a temporary solution, as you can guess that with so many companies, comes also a lot of users and more than often they don’t exit GP properly, leaving their session run on the Citrix server.. doubled down with the fact that there was no timeout set for inactive sessions, it wasn’t helping either. On top of that, the company is using FastPath for SSO and as I discovered later, FP does also have a feature for ‘inactivity’ timeoout.. As both were enabled (FP & RSTB), it becomes really though to diagnose the source of the problem.
We tried to enable the DexSQL tracing with the help of GP Power Tools, but as it occured only randomly, it was not a solution, since all users accessed GP thru 2 Citrix servers, the logs were growing fast (because enabled to all users) and it was slowing down the system.

By early 2017, we had a confirmation from Rockton that it might have been a bug related to the Toolbox ‘inactivity’ timeout feature, and thus applied the latest build with big hopes. Alas, only a few days later, the problem was back again with some users out of Asia reporting the pop-ups.. Strangely it occured mostly at Asia’s business hours (during night on east-coast) or very early in the morning on Eastern Time. My suspiscion started towards some maintenance job that would kill user sessions without further validation, but couldn’t find any tangible hints. I tried also by all kinds of back-end manipulation of the ACTIVITY table to reproduce the behavior and get the error message, as I suspeced the shared DEX.ini  to be causing this (DEX.ini stores the last company ID when a user exits GP).

At the end, as I had a conversion with my good friend & fellow MVP David Musgrave on how I could potentially enable single user tracing, without implementing indivual user DEX.ini config files, he suggested to have a look at the ACTIVITY table from the DYNAMICS DB, and check for potential triggers that could fire up at a bad time. Low & behold, it turned out that starting with GP 2015, Microsoft implemented new feature in GP that required a trigger on the ACTIVITY table to proceed with some clean-up work on company DB tables, which whne happening under a context when users were logged into another company at the same time to which they didn’t had access, would cause the infamous pop-up to show on screen.. confusing the users about the company they didn’t access to.

Read the details in David’s blog post about the underlying details and a (temporary) resolution. For now, the trigger was simply disabled on the ACTIVITY table, to confirm the source of the problem. Further action is required to resolve the issue on a long term basis with Microsoft and/or 3rd-party providers.


Categories: Citrix - TS, Dynamics GP, GPPT - GP Power Tools | Leave a comment

Using Dynamics GP in a Citrix / TS environment

I often come across discussions in forums and community posts about the problems related to the end-user parameters stored in the DEX.ini file from GP.

Now the problem with shared environments is the reality that all the users are using the program folder to launch the application, thus also the same same settings from the DYNAMICS.SET and the DEX.ini to save the parameters. This can lead to some very confusion situations…. I had users calling in and saying they started a new GP session but only get the icon in the task bar, but actually never get to the login screen.

It took me some investigation back in 2010 or 2011 when this happened the first time, and it was coincidentally at the time when some users started to request a second monitor to increase their productivity :-)…

As it turned out at that time, Dynamics GP was used on the Citrix XenApp server by the vast majority of our users (around 120) and there was a single DEX.ini file for all the users, which means that every time a user launched the application remotely, it was showing the last user ID that logged in previously and also put the main GP windows at the screen coordinates where it was closed the last time. This was not too bad as long as everyone had pretty much the same configuration for the hardware (screen and printer), but soon as people started using 2 or more monitors, and moved the main GP window off the monitor #1, then the next user would run into troubles if he/she didn’t had the same setup.

That’s when I came across a blog post from my good friend David Musgrave  (at that time) from Microsoft Australia, who wrote something about the side-effects of shared DEX.ini files and how to avoid collisions in shared environments.

His article inspired me to find a smart way to make sure when a user would start GP the first time from the Citrix server that he would get a clean pristine DEX.ini file that become he/her own and contains only the settings from their sessions. No more hidden windows and lengthy DEX.ini files that would grow out by endless printer queue entries.

So I created a small batch file that would check the presence of an existing DEX.ini file in the owner’s home profile under the system hidden AppData folder. The content of the batch file looks like this :

 @echo off
rem This file is used to launch Dynamics GP
rem from within CITRIX MF without parameters
rem echo Press any key to start the GP apps
rem pause
rem Modified version to TEST SP3 1:07 PM 7/13/2012
cd “C:\Program Files (x86)\Microsoft Dynamics\GP11SP3”
if exist %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini Goto StartGP
copy C:\Users\Default\AppData\Local\Dex.ini %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini
start Dynamics.exe Dynamics.set %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini
cd \

Save the file as a .cmd in the Program Folder location of your GP application on the Citrix server. Make sure you have fresh and pristing DEX.ini file copy in the Default user home path (see location above).  You can take the current DEX.ini file from your GP Data folder and remove any references to the ‘remembered’ printers and clear out the last user in the file :


It’s important to set the 2nd value to FALSE, otherwise GP will try to auto-login the user and this would fail since there is no user-id.

Lets assume you named your file GP_Roaming.cmd, then your new launch file command line would look like this :

“C:\Program Files (x86)\Microsoft Dynamics\GP\GP_roaming.cmd”

There is no need anymore for a parameter provided in the published application for Citrix, since everything is already passed in the .cmd file itself.

One last tip when you apply a new service pack or a year-end update to your GP. When updating your client on the Citrix or TS server, only the DEX.ini that’s sitting in the GP Data folder gets updated… none of the distributed config files from the users home profile…Remember to delete them all before given the updated GP apps free again for the users (the nice thing with published apps is that you can quickly enable/disable them).

If you don’t want to delete the files, use a VBS script or Powershell to loop through all the DEX.ini’s and make the changes.. I wouldn’t necessarily recommend this way of doing it, since during a service pack upgrade, there are quite a few changes applied to the file.

Test the new launch file with a few users and do adjustments if required. This procedure has worked pretty well for our company since about 3-4 years now and has successfully been ported to a newly built Windows 2012 Remote Desktop Application Server.

Until next post…

Update on 2015-08-21:

There is relief to all the users that have setup GP in a Citrix or TS environment. Since GP2013 was released, you don’t need anymore to have a separate DEX.ini for each user. Read on the Blog post from my friend Mariano Gomez, Dynamics GP MVP :

To me when upgrading to GP 2015 it was a real relief to not have to deal anymore with outdated DEX.ini settings every time you do apply an upgrade / service pack to your share GP client (as only the main DEX.ini got updated by the GP Utilities process). Running the GP client with wrong release information from the DEX.ini file can be very stressful as you get all kinds of strange messages and don’t necessarily think of the user’s DEX.ini (though I haven’t tested yet the user’s DEX.ini scenario after an update).

Until next post…

Update on 2016-01-25:

After we upgraded last year the GP2010R2 to GP2013R2 (not going to 2015 was a decision based on the fact that some important features from BP were missing on the Web Client PTE), I realized that the user shared DEX.ini feature was finally not so good and in some cases not useful at all. For that reason I went back to the individual DEX.ini file for each users on the TS. This way I have a much better control over the settings. I’ll post in a future blog entry, some tips on how to quickly get rid of all the DEX.ini files after an upgrade, rather then having to painfully delete them one-by-one.
Until next post…

Categories: Citrix - TS, Dynamics GP, SDT - Support Debugging Tool, System Administration | Tags: , , | 4 Comments

Blog at