Sage 100

Root cause is that Providex didn't enforce numeric data sizes in the files (only applying the mask in the UI), so conversion to SQL will fail if a number is bigger than it "should" be.  Sage made UDF numeric data types match the mask.

The only idea I have is to query CM_UDF, look at all the numeric masks, and compare the number of digits allowed with the highest value in the column (ODBC queries).

Well, fortunately SalesOrderHeader was the last problem table, so the data has now been migrated and converted.  Sage support says they have never been able to fix it because they can't replicate it.  I pointed out to them that something in the "upgrade the data" code was shrinking the size of the fields in SQL - dev should find that code and make sure it can't shrink fields.

Root cause is that Providex didn't enforce numeric data sizes in the files (only applying the mask in the UI), so conversion to SQL will fail if a number is bigger than it "should" be.  Sage made UDF numeric data types match the mask.

The only idea I have is to query CM_UDF, look at all the numeric masks, and compare the number of digits allowed with the highest value in the column (ODBC queries).

Well, fortunately SalesOrderHeader was the last problem table, so the data has now been migrated and converted.  Sage support says they have never been able to fix it because they can't replicate it.  I pointed out to them that something in the "upgrade the data" code was shrinking the size of the fields in SQL - dev should find that code and make sure it can't shrink fields.

Root cause is that Providex didn't enforce numeric data sizes in the files (only applying the mask in the UI), so conversion to SQL will fail if a number is bigger than it "should" be.  Sage made UDF numeric data types match the mask.

The only idea I have is to query CM_UDF, look at all the numeric masks, and compare the number of digits allowed with the highest value in the column (ODBC queries).

They'd have to remove the link between the UDF numeric mask and the SQL numeric data type, allowing for something like (16,3) to handle everything... and I doubt they'd be willing to do that.

If you want to try again (after taking backups of everything), delete the MAS_### database, copy back the freshly migrated MAS_### folder (assuming you have a copy) then run the company conversion again.  That should restart the SQL conversion process without having to migrate the whole system again.

Well, fortunately SalesOrderHeader was the last problem table, so the data has now been migrated and converted.  Sage support says they have never been able to fix it because they can't replicate it.  I pointed out to them that something in the "upgrade the data" code was shrinking the size of the fields in SQL - dev should find that code and make sure it can't shrink fields.

Root cause is that Providex didn't enforce numeric data sizes in the files (only applying the mask in the UI), so conversion to SQL will fail if a number is bigger than it "should" be.  Sage made UDF numeric data types match the mask.

The only idea I have is to query CM_UDF, look at all the numeric masks, and compare the number of digits allowed with the highest value in the column (ODBC queries).