Sage 100

Upgrading Sage 100 Premium from 2014 to 2017. Conversion fails at Sales Order History 5.30 with: ""Failed to drop table SO_SalesOrderHistoryDetail_0976300330: 42S02: [Microsoft][SQL Server Native Client 11.0][SQL Server]Cannot drop the table 'MAS_STM..SO_SalesOrderHistoryDetail_0976300330', because it does not exist or you do not have permission. (SY_TableConversionCommon.pvc:00438)"" There is no SO_SalesOrderHistoryDetail_0976300330 but there are _copy versions of SalesOrderHistoryHeader and SalesOrderHistoryDetail. Any ideas? KB doesn't show anything.

Revision: The referenced table does exist - I was in the wrong instance in SQL Manager. I am able to drop the table there, but rerunning the conversion fails with the same problem with a slightly different table name. I did not have this problem on the test upgrade.

Anyone on the source system (including orphans)?

I had this same issue. We increased the resources on the sql server and the problems went after. We think the conversions was timing our and leaving a bad table and pvx didn't know how to handle it... that is my theory anyways. Let me know if it works for you

Phil - Jim is correct. That's a temp table that cannot be dropped because it timed out getting to that point. In your particular area of conversion, SO_SalesOrderHistoryDetail will have a new KCANCELREASON index added to it. However it's not just simply ""ALTER TABLE table ADD INDEX index .. "". Instead, it creates 2 temp tables (one you mentioned), drops every index explicitly, add them back incl new one, renames 1 temp table to live, and drops the other temp table at the end. Last step step error because a previous step timed out. All the previous steps need to completed under default OLE DB timeout of 600 secs. One thing I've done is in SSMS goto server properties / Connection tab / Remote server connections / change Remote query timeout to 0 for no timeout. If doesn't work, there are some changes to make for sy_sql.pvc and db_sql.pvc. I didn't think of Jim's solution though which is very cool.

Setting the timeout to 0 did not solve it. Resource-wise, it is only using about 10% of CPU and 8GB out of 64GB of RAM, and there is no RAM limit on SQL. What are the sy_sql and db_sql changes?

That is right I had to delete the table listed is the error manually. The conversion chokes on it. (It doesn't know how to handle it). It is blank anyways

It was becoming obvious that this was not a timeout issue nor a permissions issue, so I decided to examine the temp table rather than delete it, and discovered it was about 2000 records shy of a full deck. The first missing record had a UDF_PROFTMARGIN with a negative value of over 1 million. Apparently the conversion was choking on that. Not sure why it wasn't a problem when calculated and saved in 2014, but I edited that value and reran the conversion and it has now finished Sales Order and moved on to creating PO history. That ""LastErrorMessage"" mentality in ProvideX is really obnoxious...give me all the damn errors along the way, or at least the First one... Thanks to everyone for their help!