I just installed the upgrade (October 2021) for GP 18.4 into a customers test environment.
There seems to be an issue when I create a payment batch and then try to select our use the payment batch. The easiest way to recreate the error is to go to Transactions, Purchasing, Edit Payment Batch. Create a new batch and save it. When you try to exit the Batch ID field on the Edit Payment Batch window you have a failure.
Column name or number of supplied values does not match table definition.
I have deleted / recreated the table via the SQL tools in Maintenance in Dynamics GP. I drop and recreate the tables and stored procedures, error still persists.
I remember something similar to this in November 2019, but I cannot find how we resolved it.
Anyone seeing this issue and can help out?
Thanks for this update. I do upgrades all the time and usually get clients to 16.00.0716 before upgrading to 18.3.x or 18.4.x. I will test if this is also true coming from 16.00.0716.
I wonder if there some script that can be run first. Can anyone from Microsoft chime in on this?
Here is the solution, I hope this helps other customers and / or partners that are planning to upgrade. If your environment that you are upgrading from is 16.00.864 (R2) you must upgrade to 18.3.1290 first (this is the mid year release) MicrosoftDynamicsGP18-KB4569498-ENU.msp
Once it is upgraded, then you can install 18.4.1361
Perhaps there will be (maybe there is) some guidance on the upgrade path.
David, thanks for answering earlier...
I changed the security on the Alternate Forms and Reports to use the GP Windows, nothing modified and removed the Reports.DIC and Forms.dic from their terminal server and their SQL Server (no workstations have GP installed, all terminal server environment). Issue persists.
Non-logical reasoning tells me it is something related to their environment. They have 6 GP companies, and I confirmed at least one other company has the same failure. I had turned on the DEXSQL trace, and the table and stored procedure that fails are below.
PM10300
pmPopulateEditCheckBatchVendorTemp
I assume if I created / edited the payment batch by selecting instead of going straight to the Edit Payment Batch window, it would be a different stored procedure.
I took another customer that is on 18.3 and grabbed the SQL Script for the single stored procedure above and put it into my failed environment. Fantastic -- it works!
This particular stored procedure is bad pmPopulateEditCheckBatchVendorTemp
But how? I upgraded from and to below, nothing in between
Previous GP version 16.00.0864 (R2)
Upgrade to 18.4.1361 (2021)
The upgrade ran without warning or error.
I don't know how to get the tables and stored procedures back in alignment? I don't know how to convince myself there is not something else that could be wrong.
I can manually get the stored procedures from a working environment and update the "bad ones" but this does not seem safe. I see at least 6 stored procedures that are suspect, I am convinced there are others?
I thought using the SQL maintenance to drop and recreate the table and stored procedures above would be the way to go. The maintenance does drop and create the table if I choose the PM Payment Work, but not the stored procedures.
The dates on the stored procedures are 12/20/2020 in the failed environment, the working environment the same stored procedure dates are July 2021
I am thinking of starting the upgrade over, upgrading to 18.3 first them 18.4? This is fine for us, but not good for the GP population as a whole... If I have time to do this I will report back.
This could be caused by an out of date custom forms or reports dictionary. Please test without any custom dictionaries.
Do you get the name(s) of the tables?
Regards
David
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 290,522 Super User 2024 Season 2
Martin Dráb 228,441 Most Valuable Professional
nmaenpaa 101,148