![]() ![]() ![]() Since the JE entry was quite lengthy and composed by over 350 lines, it took some time to scroll thru all the Debit & Credit values to check for unusual numbers. So much for the DEXSQL trace, but what could actually cause GP to run into an Arithmetic overflow? Next to the statement above came the lines that would throw the error message on screen and then put the batch into recovery mode. This came up right after about 20 times the same command was called to execute the glpPostBatch, which seemed to be some timeout limit, though I can’t confirm that for sure. What I found was quite strange to me as I had never seen such an error message in my entire GP life : What I did next was to use the GP PowerTools to run a DEXSQL trace file just right before starting to post the batch, and stop it right when the error would come up. The next step was to check the related entries in the GL10000 & GL10001 tables, but nothing suspicious either there. My first hint was to look into the SY00500 table that holds the batches in the company table, but couldn’t see anything unusual. ![]() But in my case, this wouldn’t work and no matter how we tried to post this batch, it would fail and get into recovery mode. The simple fix would be to jump to the last line and delete the line. Most of the time it can be that your JE entry contains a blank line at the end of the transaction lists, as it has been reported in the past by some other users in the community forums. The message means nothing and doesn’t give you any hint about what the real problem might be. ![]() The full message actually starts with “The Stored procedure glpPostBatch returned the following results: DBMS: 0, Microsoft Dynamics GP: 20052”Īnd that is the problem. This is quite a common error message you may get in Dynamics GP when trying to post a GL Batch in Financial. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |