Hey Beat,
For a somewhat vague upgrade error like this I would recommend capturing a DEXSQL.LOG while sending these tables through the upgrade again. To upgrade them again you'll need to first run the following query to find the failing table records:
SELECT b.fileOSName, a.fileNumber, a.PRODID, a.Status, a.errornum, a.errordes, c.CMPANYID, c.INTERID
FROM DYNA)ICS.dbo.DU000030 a
JOIN
DYNAMICS.dbo.DU000010 b
ON a.fileNumber = b.fileNumber
AND a.PRODID = b.PRODID
JOIN
DYNAMICS.dbo.SY01500 c
ON a.companyID = c.CMPANYID
WHERE (a.Status <> 0 or a.errornum <> 0) and a.Status <>15
You will need to remove the failed tables from the DU000030 table, e.g.:
DELETE DYNAMICS..DU000030
WHERE status in (70,135)
Then, with a DEXSQL.LOG enabled run GP Utilities and recreate the issue.
Within that log you'll want to search for the failed tables (POP10300 and POP30300). At that point you kind of need to be familiar with the sequence of events for a table upgrade to know where it is going wrong. Generally speaking the process is:
1) Rename the table (e.g. POP10300 to P10300OP)
2) Create a new POP10300 at the destination version structure, including all of the zDP procs and indexes
3) Insert the data from the renamed table to the new table including default or calculated values for any new columns
4) Drop the renamed table
As you scroll through the log after the table is initially renamed you will want to look for any errors messages. You'll know the process failed when it rolls back by renaming the P10300OP back to POP10300.
Some typical issues are going to be things like bad structure for the table in the previous version, which would be a rollback after a SELECT statement against the renamed table.
Another error we see is in reference to a zDP procedure already existing. These should be dropped earlier in the process, but if they exist then the upgrade tries to create them again you'll need to manually delete them in SSMS before running the upgrade again.
Hope this helps point you in the right direction,
Lucas
