Often we get requests to release a lock happened in GP when a user tried posting a transaction or batch. And it gets stuck and the user is not able to reopen the Transaction Entry (Ledger/Subledger) form.

This is contributed to the DEX_SESSION and DEX_LOCK tables in addition to ACTIVITY, SY00800 and SY00801. This is clearly explained in the KB article #866440.

Some of the consultants often kill the Dynamics.exe process to get out of a stuck session in other to allow the concerned user to log on back and do his routines, without knowing the impact of it. Once the user logs back in after this KILL, he/she would not be able to reopen the Transaction Entry form where they got stuck initially. This in addition to deleting the ACTIVITY record for that user.

My piece of advice: Always note down the SQL Session ID which is there in ACTIVITY table before deleting the ACTIVITY record. There are two reasons why we want to do this. DEX_SESSION and DEX_LOCK tables would have this SQL Session ID as the reference to that particular user’s session. And if we don’t know this, we won’t be able to delete the respective records from these tables (as explained in the KB article).

I recently had to face the similar situation where I was left with DEX_SESSION & DEX_LOCK records without having a reference to the SQL Session ID, as the ACTIVITY record was deleted before hands. I had to spend some quality time on that to restore the system for that User ID back working.

This is really important and I am sure experienced consultants would agree with me in this regard. Always pay attention to these tables and respective records before do something hasty and repent it later.

VAIDY