Announcements
3,494
Hi:
I'm on the last leg of the upgrade path from GP 2013 to GP 2013 R2 to GP 2016 R2 (16.00.0885) to GP 18.3.1245.
Here on GP 18.3.1245, GP Utilities seems to be "stuck" on the Posting Definitions Master table for one company, albeit the largest of the seven.
This did not happen, when I upgraded GP 2013 to GP 2013 R2 and then to GP 2016 R2.
It has been on this table for nearly 6.00 hours.
Shall I simply "ride it out"?
John
John-
I had forgotten about this problem! Went through this too -- there was a trigger on SOP30200 for SmartConnect I had to disable before upgrading from 2015 R2 to 18.2. The upgrade kept hanging!
Glad it's resolved.
Joe
Well, here was the solution from Microsoft.
There were third-party triggers on both the SOP10100 and SOP30200 tables. These triggers are not needed by the client, anyway.
So, once we disabled these, we re-ran the upgrade and all was well!
Whew!
John
Well, removing those stored procedures was a good thought and a good try. Unfortunately, doing so made no difference.
Hopefully, my PartnerSource access will be restored soon and I can get the silver bullet.
Thanks though, guys, for your help!
John
Time to time we see tables fail when it attempts to create the procedures before removing them, when that happens we usually see a message in the dexsql.log stating just that, that the object already exists.
That being said, you can definitely try manually deleting the zDP_ procedures for the SY00500 table, which can be done via SQL Maintenance or manually through SQL Server Mgmt Studio, then test the upgrade again.
I'm really late to this party, but just a thought about the upgrade freaking out on SY00500.
Would it help anything to drop all of the stored procedures in the previous version? Use SQL Maintenance in GP, drop all of the stored procedures and then add them back?
Just thinking out loud.
Joe
At this point, I would say to open a support case to have an engineer look at this upgrade with you, as it's too tough, if not impossible, to really troubleshoot upgrade issues like this via forums with this back and forth and not really the intent of the forums.
As mentioned previously, if the current upgrade is still hanging on the SOP00500 table, and there are no error messages being showed by GP Utilities nor the 'failed tables' script, I would try re-creating the table at the 'old' version with any data intact, if the db_status of this company database in the DB_Upgrade table is 23 or less, and re-creating the table at the 'new' version with any data intact if the db_status is greater than 23, meaning it has gone past the section of the upgrade where it updates the existing tables.
My thoughts are, since nothing shows in the 'failed tables' script for this table, that it's past the section of updating tables.
Once that is done, test the update again to see if that resolves this issue with this table or not, or if it throws an actual error, then go from there.
If the issue remains, test without any data in the table to see if the upgrade gets past that part.
The dexsql.log would need to be used, as also mentioned, to verify what the upgrade is hanging on and that it's staying on that particular script.
This is about all I'd have for this upgrade forums question. Anything forward, we would need a support case to look at it with you.
Thanks
So, what would the next step be?
John
The original start of this forum was the SY00500 table hanging for 6-12 hours, which is the Posting Definitions Master table.
The only mention of SOP10100 was at the very end of the dexsql.log snippet you copied to this forum:
UPDATE SOP10100 SET Workflow_Status = 9 UPDATE SOP10100 SET WorkflowPriorityCreditLm = 1 WHERE WorkflowPriorityCreditLm = 2 or WorkflowPriorityQuote = 2
When an upgrade is just hanging on something, we'll try to start a dexsql.log to see where or what it is hanging on, then try to determine why.
That is if the GP Utilities isn't actually failing with any type of error message and/or nothing is showing in the 'failed tables' script as failing.
With a dexsql.log running, we'd let it run to the point where it is seemingly hanging on something, then while Utilities is still going, open the dexsql.log and look at what is at the very end of the log.
Later, look at the dexsql.log again to verify it is actually still at the same exact script as before, or if it has actually moved on to something else.
If it remains showing the exact same script for a long period of time, then we would try to determine what the issue is and how to get past it.
That being said, we haven't seen any case volume to suggest there are any issues with SY00500 nor SY10100 table in any of our upgrades.
Thanks
But, I thought that it was mentioned yesterday that the issue instead is with SOP10100 and not SY00500. I don't care. I'm just confused.
Well, that's fine. But, yesterday, we did try with an empty SY00500 table and got the same results.
What would be the next step, then?
Thanks!
John
The log doesn't give us enough information as to why the SY00500 table is hanging for 6 to 12 hours during the upgrade.
From the log, we see it do a SELECT COUNT on whatever this SY00500GP19Y object is, then it removes constraints and indexes from SY00500, then adds back primary key and indexes to SY00500 before granting permissions to SY00500 to DYNGRP.
It then looks at DU000030 before then doing a BEGIN TRAN SELECT COUNT(*) against this SY00500GP19Y object in the CCCT1 database.
It then attempts to drop the dex procs for this object, giving multiple messages that it can't drop them because of permissions or they don't exist.
Then Utilities looks at the DU000030 and then DU000010 table again before running the update on the SOP10100 table, where the log ends.
I think the question is more what is this SY00500GP19Y object and its connection to SY00500?
Is it some type of replication table that is tied to the SY00500?
Are there custom triggers on the SY00500 table for this other object?
If every other company database upgraded successfully, that would show there isn't any 'known issue' with the SY00500 table, so it becomes what is unique with it in this company database, but the information in this forum isn't enough for us to tell you exactly why this table in this one company is hanging for several hours.
Some things we would try, in the absence of any error information as to why the table is doing what it is doing, is to drop and re-create the table with any data intact and run the upgrade again.
If it still hangs, try without any data in the table and see if that goes through.
Without any failed table record for SY00500 in the DU000030 table, we can't manually tell Utilities that this table has been upgraded and to skip it.
Thanks
#1
Martin Dráb
601
Most Valuable Professional
#2
Abhilash Warrier
416
#3
Adis
384
Super User 2025 Season 1
Share
Report
All responses (
Answers (
