A few versions ago, Microsoft included a feature in Dynamics GP meant to manage this issue at the user level - very cool. The tool is known as the Batch Recovery Routine. Accessed in Dynamics GP by clicking on Tools > Routines > Batch Recovery -- see image one below
Image 1 - Batch Recovery Routine Navigation |
When a batch is not balanced, a computer or network connection goes to sleep, or someone trips over a power cord... a batch gets stuck in posting. When this happens, the first step in resolving the problem is to access the Batch Recovery window -- see image two below.
Image 2 - Batch Recovery window |
The next step in the troubleshooting process is to get everyone out of Dynamics GP, then view the contents of the following tables to verify that all users are logged off: DYNAMICS..ACTIVITY, DYNAMICS..SY00800, DYNAMICS..SY00801, TEMPDB..DEX_LOCK, and TEMPDB..DEX_SESSION.
This is important, because sometimes, there really is another user locking the batch, and in other cases the lock is a glitch/remnant of a connected user. Run the following queries in SQL query analyzer (SQL Server Management Studio) - the queries call out the databases they access.
SELECT * FROM DYNAMICS..ACTIVITY
SELECT * FROM DYNAMICS..SY00800
SELECT * FROM DYNAMICS..SY00801
SELECT * FROM TEMPDB..DEX_LOCK
SELECT * FROM TEMPDB..DEX_SESSION
Note, when all users are logged off from Microsoft Dynamics GP, these quiries will not produce any results. So, if there are still records in these tables, they need to be removed. To clear the stuck records use all of the following scripts - if a table is empty already, they will do no harm.
DELETE DYNAMICS..ACTIVITY
DELETE DYNAMICS..SY00800
DELETE DYNAMICS..SY00801
DELETE TEMPDB..DEX_LOCK
DELETE TEMPDB..DEX_SESSION
If no results were returned, then the batch isn't locked, and only needs to be reset in the SY00500 table -- this table exists at the company, not system level. Replace XXX with the batch number or the name of the batch that you are trying to post or select in Microsoft Dynamics GP and run the query below against the company database (when folks get no results here, they typically find they are connected to the master or DYNAMICS database.
UPDATE SY00500 SET MKDTOPST=0, BCHSTTUS=0 where BACHNUMB='XXX'
In order to implement the fixes described above you will require SQL Skills and access to SQL Query Analyzer. If those are foreign concepts, be nice to the nerds in your life. Your GP Partner, Company DBA or Outsourced IT resource will likely be able to run these queries for you.
Harry,
ReplyDeleteNice post. Here is a script that will clear orphan session records that you can run without having to make all users exit GP:
delete from DYNAMICS..ACTIVITY
where USERID not in
(select loginame from master..sysprocesses)
GO
delete from tempdb..DEX_SESSION
where session_id not in
(select SQLSESID from DYNAMICS..ACTIVITY)
GO
delete from tempdb..DEX_LOCK
where session_id not in
(select SQLSESID from DYNAMICS..ACTIVITY)
GO
delete from DYNAMICS..SY00800
where USERID not in
(select USERID from DYNAMICS..ACTIVITY)
GO
delete from DYNAMICS..SY00801
where USERID not in
(select USERID from DYNAMICS..ACTIVITY)
GO
These look like they would work fine, if the particular user, locking up the batch is out of GP, before they are run. Excellent contribution.
ReplyDelete