The stored procedure glpBatchcleanup returned the following results: DBMS: 0,Microsoft Dynamics GP:20486

I have seen this problem before when developing using VSTools. Could you please provide the context in which you are receiving these errors. Does the error occur when running routine GP processes or are 3rd party products being executed.

We periodically get these.

After getting this message once, I looked in the SQL error log file and discovered that it occurred when one transaction was doing a SELECT against the SY00500 table and another was running the glpBatchCleanup routine (which, I believe, is the last step in the posting process). Apparently both needed exclusive access to the SY00500 and the glpBatchCleanup task was chosen as the deadlock victim.

From what it seems to me, it's a random occurence that requires two or more people or processes accessing batches at the same time.

Sometimes the original batch data isn’t cleared out from the entry tables (SY00500, GL10000, GL10001, for example) although the batch was actually posted. To confirm, use the Inquiry screens to look up the transactions (both in the appropriate submodule and the general ledger); if things look OK, use SQL to delete the batch data from the SY00500, GL10000, and GL10001 tables (unless someone has a better idea on what to do).

We just had this happen.  Does anyone know if check links would clean up the rogue entries in the tables?

I have just recently started having trouble with this same error message myself.  It also happens on a server running a macro style process that processes transactions automatically with no user interaction.  Whenever this error occurs it interrupts that process, which is third party.  I found a KB article from microsoft on the error, but it doesn't seem to be a permanent solution to prevent the error from happening to begin with.

Here is the article: support.microsoft.com/.../860710

Any other help would be much appreciated.

In my case I eventually found the cause and a solution to the glpBatchCleanup error. I was calling a particular function that once it had completed, triggered a second function to run. Because the first function had finished, my code start performing its next processing steps even though the second triggered function was still running. I eventually resolved the problem adding code following the completion of the first function, that checked database records to determine whether the second triggered function had completed. Once I had detected the second function was complete, I continued the processing of the next action.

If you are purely using GP Macros, the above solution may be beyond the scope of Macro programming capability. If you would like to discuss possible technical solutions, jump onto my web site, and send me an email, and together we may be able to come up with a solution.

Regards

Andrew Dean

Thanks for your follow-up Andrew.  Unfortunately the program that we are running is a third party tool that I don't have access to the code of.  It is an Accellos solution for using handheld scanners to process transactions that they normally would through the GP screens.  The host machine acts like a normal user logged into GP and you can see transactions process in the GP window just as if you were doing them yourself.  In our case we process a lot of MO's and this message comes up during the MO receipt transaction.  When the error comes up, it then interferes with the transaction that follows.

The error actually happens during a normal GP MO receipt process and could actually happen to a real life user doing the transaction using their GP login.  The batch that is trying to post is the finished good adjustment batch putting the finished good into stock.

If I log out of Great Plains and then log back in I am able to recover the bad batch in Batch Recovery and it then processes just fine.

Any other suggestions would be great.  Hopefully the additional information makes sense.

Thanks,

Mike

This is still an issue.  I have seen articles on Microsoft's website about clearing the DEX_LOCK and DEX_SESSION tables.  Since these processes are logged in all the time is it worth clearing these tables at night?  It doesn't happen till morning after there has already been activity on the system for a while.

Any other help would be greatly appreciated.  This has become almost a daily happening now.