I have a very in depth description of the upgrade testing before produciton upgrade and the issues that I encountered during the upgrade of the production data. I will give a short description here and if someone wants the full detail I can upload it.
I have a feeling I know what the issue is, but need someone else's opinion please.
So a new server windows sql 2016 w sql 2014 running was created so the production machine could be moved to this new server. Normally I will not do an upgrade and server move at the same time-- but the client was persuasive and I gave in!
So basically I did a test upgrade on the new server ( 30 databases) and all was flawless
upgraded to GP2013 R2 and added the last year end sp so it would take me to a version that could then be directly upgraded to Gp2016 R2 and then added latest service pack.
Then a month later after accounting gave me the go ahead, I followed all the upgrade instructions, moved the databases to the new server, updating sql compatibilty, running grant sql scripts, updating DB owner to DYNSA and then proceeded with the produciton upgrades. All kinds of errors " coudl not drop temp table" . I worked on it all weekend and had one remaining database to upgrade but it was still running at 7 AM so the accounting team said they cannot loose any productive time, so the upgrade was cancelled and I waited another 2 weeks to get to a time frame that worked for them and started again.
In the mean time I removed GP 2016 install and 2013 install and reinstalled fresh. The client is only using GL and about 4 companies are using PM so not a complicated system at all. I ran all the checklinks and datamaintenance on all databases and started the upgrade. ent pretty smooth but 4 companies had error messages. 3 of the 4 only used GL and not PM and no company used POP. The same error was encountered on all 4
unable to upgarde PM40100, PM10000, PM20000, PM30200, UPR00100
I could not get past the error even though those tables had no data to convert. after research I tried to drop and create the tables-- the process indicated it worked but restarting the upgrade on these companies, the same error occurred.
Yes I did delete the DU00030 table before doing the last upgrade--
So then I did more research and since these tables were not used, I updated the file status to 15 and tried again on these 4 databases. Well this time a different message which I am sure is due to the status change
create view(dbo) popWork Transactions blah blah blah failed, you say okay and it says workflow_status is not a valid column
so after thinking about the issue I decided to copy the view from a company that did sucessfully upgrade and script it as a create, then create the view in these 4 companies-- same error workflow_status is invalid column.
I researched POP10300 tablepurchasing receipt work table,purchase order work and every table that I found listed in the create error... worflow_status is a valid column name
SO
Why did some companies upgrade without issue and others did not?
I have all the detailed messages and process outlined in a 13 page document if you want more detail but I really need assistance. I have never had to tell a client the upgrade failed!
On the second upgrade attempt the errors occured during the first step- upgrading to gp2013 R2 and year end service pack. I never got to the GP2016 upgrade!
so it worked twice before but not the last time!!!
Thank you in advance for any assistance you can provide
Carolyn
*This post is locked for comments
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... 291,113 Super User 2024 Season 2
Martin Dráb 229,918 Most Valuable Professional
nmaenpaa 101,156