Previously, in Part 1 we discussed Batch Edit Lists and how they can help you, including preventing batches that get stuck because of a transaction-level error. Sometimes, however, batches stick for an entirely different reason.
During posting, the bulk of the processing actually takes place on the SQL database server rather than on your workstation. But at several points in the process, the server needs to communicate back to your GP client to pass the results back and send any instructions for the next steps back to the SQL server. And then in some modules (GL in particular), a final necessary step is sending the report data back to the client to print the posting journals – and if they don’t print, it doesn’t finish posting.
It’s during those back-and-forth periods that the process becomes vulnerable. If communication is interrupted, even very briefly, the posting process can fail or only partially complete.
What can cause one of these disruptions? Anything that disrupts network communication will do it. Power outages, network hardware failure, or workstation crash are the obvious and memorable ones. But a network problem doesn’t have to last long or be noticeable to cause a posting problem.
For that reason, GP is not supported over VPN or wireless connections, as they can be a little fragile and easily overwhelmed. Anyone who posts should be using an actual Ethernet connection on the same network as the server. (If you’re using a terminal server that you access remotely, it’s the terminal server’s connection to the network, rather than your workstation’s connection to the remote server, that matters most.)
Even if you are hard-wired to the network, take note of any symptoms of network connectivity issues on your workstation such as:
• Loss of connection to mapped drives or shares
• Intermittent printing difficulties
• Loss of connectivity to the Internet
• Program crashes or network errors
There are a few things you can do to keep conditions as ideal as possible for safe posting:
• Use a wired network connection
• Reboot your workstation regularly
• Exit GP completely at the end of every day/log in fresh every morning
• Log out of GP if you won’t be using it for several hours
• Print to screen first rather than directly to the printer
• Watch out for other applications that hog memory over time (web browsers, in particular, can be a problem – close and re-open occasionally)
• Do not ignore connection or window errors in GP – close the program and log back in if you are already having connection problems
• Be cautious about extremely large batches – close unneeded applications and don’t click around in GP while posting
• Watch out for weather, construction, wiring, or other environmental issues that might increase the risk of power outages
For help with stuck batches or other Microsoft Dynamics GP related issues, please contact Customer care at 866-668-3699 or email@example.com
Also be sure to check out Part 1. Dynamics GP Batch Edit Lists vs. Bad Data and Stuck Batches and Part 3: ‘Unsticking’ Stuck Batches
Customer Care Manager
FMT Consultants, LLC