*This post is locked for comments
*This post is locked for comments
Johnathan,
I'm running into the same issue as Angel, but what I don't get is why in the hell is the module installation (chunk file ?) inserting an entry in the DB_Upgrade table for Version 8.0.0 , as I added the RED module (1045) from the 2013R2 Media (thru Add/Remove Programs - Change).
This is what I got after installing the .chk file :
PRODID db_verMajor db_verMinor db_verBuild db_verOldMajor db_verOldMinor db_verOldBuild db_status start_time stop_time
1045 8 0 0 8 0 0 0 2016-02-04 14:57:19.880 2016-02-04 14:57:19.880
I've no trace of any previous installation of the RED module, no tables, nothing.. To me this sound like a bug from Microsoft that was not fixed past GP 8.0... :-).
I'm just going to delete that entry and see what happens. BTW, this is a TEST GP2013R2, currently at 12.0.2038 (with the latest YE Tax update)...
EDIT: I found out from where this entry came... somehow one of our dozen GP companies had remaining old table entries from the RED module... that what caused the issue. I deleted the PPxxxx tables and than I was able to install for the other companies.
That's right. I'm not upgrading, it's a test company so i'll just let it be for a while.
Thanks
But Angel you cannot upgrade the module now. That is why I said you can only change these records in these tables if you were 100% sure the modules were on GP 2013 version.
Jonathan, you're totally right.
The issue persists because of this company in row 4, but the problem was brought to me after the user reported errors when trying to log in to company in row 1 as well, so I guess something happened during the upgrade to 2013.
After editing DB_Upgrade and DU000020, I got rid of the errors. We still have to upgrade this feature from 8 to 12, but that's a different matter.
Thank you very much, I've learned a lot today.
The issue isn't with row one in the first db_upgrade results, it is with row 4. If you look at the DUinstall.log file now I bet it says it cannot upgrade from version 8. You will need to delete that line and insert in a new one for that company.
The faulty company is row 1 for DB_upgrade and row 6 for DU000020 (see image)
.
I'm not getting this error anymore:
"Database setup has not been completed for Microsoft Dynamics GP. Use Microsoft Dynamics GP Utilities to complete the database setup before starting Microsoft Dynamics GP" and tables for R/ED have been created, but tables for Electronic Reconcile are still missing and I'm still getting:
"There was a problem ascertaining product version information. Microsoft Dynamics GP Utilities will now exit. Check DUinstall.log for more information".
If you have the right records in both tables you wont be getting the errors. Post the following script results:
Select * from Dynamics..db_upgrade where prodid = '1045'
Select * from Dynamics..db_upgrade where prodid = '1428'
Select * from Dynamics..DU000020 where prodid = '1045'
Select * from Dynamics..DU000020where prodid = '1428'
The first thing GP is going to check when logging into Utilities is the db_upgrade. If there are no records in that table for a module GP will go look to see if the version check table exists:
1045- PP000001
1428- ME142803
If the version check table does not exist it will reinstall/reinitialize the module (drop all object and recreate them). However if it does find that table it will insert a record for GP 8 (or 9 depending on when the version check table was introduced for that module) into the db_upgrade table.
I am not sure how this has been working before as when you log into GP it is going to check the DU000020 table and when you log into Utilities the db_upgrade table. If these were added at GP 2013 then you could insert records into these two tables for this company but you need to realize that you have to be 100% sure that these modules are actually on GP 2013 version otherwise you are going to start getting errors in the application.
André Arnaud de Cal... 291,735 Super User 2024 Season 2
Martin Dráb 230,466 Most Valuable Professional
nmaenpaa 101,156