A stuck batch usually appears at the worst moment: during month-end, in the middle of a check run, or while auditors are waiting for a report. Microsoft Dynamics GP (Great Plains) shows the batch as Posting, Busy, Marked or Locked, nobody can edit it, and Batch Recovery either does nothing or returns the same message again.
This article explains, in plain terms, why batches become stuck in Microsoft Dynamics GP, what to try first, and how a system administrator releases the batch safely when Batch Recovery does not work. The database steps are meant for the person who manages your SQL Server, and we explain the business checks around them so that the finance team knows what to expect.
What a Stuck Batch Is and Why It Happens
When Dynamics GP posts a batch, it does not move all transactions at once. It marks the batch as being posted, copies each record from the work tables to the open or history tables, and only then deletes the originals. If that sequence is interrupted, the batch keeps a status that tells every other user to stay away, even though nobody is working on it any more.
The causes we see most often are:
- The network connection to SQL Server dropping during posting.
- A workstation freezing, or a user closing GP from the taskbar while posting is still running.
- A power cut or a server restart during month-end.
- A report window hidden behind another window, waiting for the user to choose a printer.
- Transaction errors, such as a closed fiscal period or unbalanced distributions.
First Steps: Batch Recovery and Quick Checks
Before anyone opens SQL Server, try the standard tools in this order.
- Ask the user who posted the batch to look for open windows. A report destination window or a message box hidden behind other windows can keep posting active.
- Open Batch Recovery under Tools > Routines > Batch Recovery, select the batch and choose Continue. In many cases GP finishes the posting or returns the batch to its entry window.
- Print the batch edit list if the batch returns to entry, and correct the errors it shows before posting again.
- Confirm that the user has permission to post and that the fiscal period is open.
If the batch is still marked as posting or busy after these steps, Batch Recovery cannot help further, and the problem lies in the database records that link the batch to a user session.
Why Batch Recovery Sometimes Does Not Work
Batch Recovery can only complete a posting that Dynamics GP still recognizes as unfinished. It cannot remove the activity records that tell Dynamics GP a user is still working on the batch. When a session ends abnormally, those records remain in the system database and in SQL Server’s temporary database.
Dynamics GP then sees a batch that appears to belong to an active user. Batch Recovery leaves it alone, and other users receive a message that the batch is busy or being edited. The same leftover records can also stop the affected user from signing in again, with a message that they are already logged in.
The fix is therefore to clear those leftover records and reset the batch status, which is what Microsoft’s published procedure does.
Precautions Before Any Database Change
We emphasize these precautions because the steps that follow change data directly in SQL Server.
- Everyone must be out of Dynamics GP: The scripts clear session records for all users, so anyone still working would lose their session.
- Take a full backup: Back up the company database and the DYNAMICS system database, and keep the backups separate from older backups.
- Write down the batch details: Batch ID, module, number of transactions, batch total and the user who posted it.
- Check whether anything has already posted: The section on partially posted batches below explains why this matters.
- Use someone who knows the Dynamics GP tables: A mistake here can leave transactions half in the work tables and half in history.
Releasing the Batch in SQL Server, Step by Step
The steps below follow Microsoft’s published resolution for batches held in a Posting, Receiving, Busy, Marked, Locked or Edited status.
-
Confirm that all users are out. In SQL Server Management Studio, run the following. When nobody is logged in, all five tables should be empty.
SELECT * FROM DYNAMICS..ACTIVITY; SELECT * FROM DYNAMICS..SY00800; SELECT * FROM DYNAMICS..SY00801; SELECT * FROM TEMPDB..DEX_LOCK; SELECT * FROM TEMPDB..DEX_SESSION; -
Clear any records that remain. Rows that are still there after everyone has exited are leftovers from the interrupted session.
DELETE DYNAMICS..ACTIVITY; DELETE DYNAMICS..SY00800; DELETE DYNAMICS..SY00801; DELETE TEMPDB..DEX_LOCK; DELETE TEMPDB..DEX_SESSION; -
Reset the batch status in the company database, replacing
XXXwith the batch ID. If the same batch ID exists in more than one module, add the batch source to the condition so that only the stuck batch changes.UPDATE SY00500 SET MKDTOPST = 0, BCHSTTUS = 0 WHERE BACHNUMB = 'XXX'; - Open GP and find the batch in the module where it was created. It should now be available for editing.
Microsoft’s separate article on the Posting Interrupted status adds two further actions for difficult cases: restarting the computer that runs SQL Server, and running Check Links on the affected series.
Important: These SQL commands directly modify database records. Have a qualified Dynamics GP administrator or support professional review the situation before running them. The DELETE statements above affect session and activity records across users, not just one batch. Confirm that all users are logged out, verify backups, and follow the applicable Microsoft procedure for your environment.
Checks After the Batch Is Released
Releasing the batch makes it available again, but it does not prove that the data is complete. Before posting, work through these checks.
- Print the batch edit list and compare the number of transactions and the total with the details you noted earlier.
- Correct any errors that the edit list reports.
- Post the batch and keep the posting journals.
- Run the module’s standard reports, such as the aged trial balance or the general ledger trial balance, and compare them with the figures from before the problem.
- Run Check Links for the affected series if anything looks out of balance.
Partially Posted Batches: When to Stop
The most serious case is a batch that stopped halfway, with some transactions already in the open or history tables and others still in the work tables. Resetting the status and posting again can then create duplicate entries in the subledger or the general ledger.
Suspect a partial posting when the batch total on the edit list is lower than the original total, when some documents already appear as posted in the inquiry windows, or when a posting journal was printed for part of the batch. In that situation, stop after the backup. Analyzing which records sit in which tables requires someone who knows the module’s table structure, and the correction usually involves removing duplicate records before the batch can continue.
This is the point at which most companies call their Dynamics GP support partner, and it is better to call before posting again than after.
How to Prevent Stuck Batches
Most finance teams will recognize the first two causes listed earlier from their own experience. A few habits remove most of the risk.
- Close Dynamics GP through the File menu and Exit, never from the taskbar or by ending the program.
- Post large batches on a stable wired connection or directly on a Remote Desktop server, not over a weak Wi-Fi or VPN link.
- Send posting reports to the screen or a file, so that no hidden printer window can hold up posting.
- Confirm fiscal periods and posting permissions before month-end begins.
- If a customization or third-party product runs during posting, test it after every update.
- Stay on a current version, planned through a regular Dynamics GP upgrade, so that known posting defects are already corrected.
- Include safe posting and exit habits in Dynamics GP training for new staff.
How Nevas Technologies Helps
Nevas Technologies has supported Dynamics GP for more than 20 years, and stuck batches are a familiar request for our support team, especially at month-end. Our consultants check the session records, confirm whether anything has already posted, release the batch and verify the totals with your finance team. Where stuck batches happen repeatedly, we review the network, the posting setup and any customization involved.
For an organization preparing for the end of Dynamics GP support in 2029, it is worth knowing that posting in Dynamics 365 Business Central is processed on Microsoft’s servers rather than on the user’s workstation. We can explain the difference as part of a Dynamics GP to Business Central migration review.
Frequently Asked Questions
Can a user release a stuck batch without SQL access?
Only through Batch Recovery. When that fails, the remaining steps need database access, so a system administrator or your GP partner must carry them out.
Will we lose the transactions in the batch?
Not if the batch was untouched by posting. Resetting the status only makes the batch available again, and the transactions stay in it.
Is help with stuck batches part of our GP license?
Your Dynamics GP license and enhancement plan give you the software and its updates. Hands-on help with problems such as stuck batches is normally provided by your Dynamics GP partner under a support agreement.
How long does the fix take?
A simple stuck batch can usually be released within an hour once everyone has logged out. A partially posted batch takes longer, because each record has to be checked.
Conclusion
Summarizing the approach: try Batch Recovery first, then clear the leftover session records and reset the batch status, but only after a backup and only when you are sure nothing has posted yet. Most stuck batches are released quickly, and the costly ones are those posted a second time without checking.
If a batch is stuck now, or the problem keeps returning, contact our team or request a quote for Dynamics GP support.