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.
The Dynamics GP Geek Blog 
Leave a Reply