I’m getting an error (SQL 8115) when trying to upload objects to one of our Navision 3.70 databases.
The error says: Arithmetic overflow error converting expression to data type datetime.
Have anyone seen this error before?
What is the exact change you have made in the database? Are you trying to convert a decimal to a datetime field?
There is some overflow in the database created by importing the fob.
Maybe you can try to find the differences between the old g/l entry table and the one you are importing.
Actually it was me who did the import, but one of my co-workers.
But we are trying to import a number of objects into a Navision 3.70 (SQL and Japanese collation) and we are getting the error on several tables (incl. 17). It works fine when importing into our other databases incl. the test database.
Eric,
I do not have experience with this specific errormessage and when you search it in combination with navision, there are no results.
If you google “Arithmetic overflow error converting” you get some results regading typechanges.
Maybe this one database has some data that causes the problem. What other tables have problems? Are they releated to 17? What about db-test?
I see that the message is “converting Numeric to data type numeric”, NOT “converting Numeric to date type numeric” so I don’t think it is aything to do with date fields.
What it looks like to me is that there is a SIFT field being imported that has maybe the decimal places hard coded instead of using the format field.
What this can cause, is that in calculating the value, it can’t display or calculate the correct number of decimals.
Since its Japanesse, and they have Jen which have differnt decimals, I would look at this as the forst point of call.
I have also seen this error in a C/SIDE database, it was because of a GL Entry that had 5 decimals, and the flow field in the GL Account table had a really huge total number, thus the one very small number (it was some rounding junk error of 0.0001) added to the big total to give a sum index something like 1,000,000,000.00001. In any case it will most probably be a decimal rounding error in a sum index field, or a very ver small value in a gl entry. If the value is 0.0001 it will be east to find, if its 100.0001 it will be a huge job to find.
See this as base description of the problem. Try to compare result of SQL command:
SELECT @@MAX_PRECISION AS ‘Max Precision’
on both servers (Live and Develop). Try to check what changed in field settings in your objects…
Hello Just another suggestion, export the object as text and import them as text.
I had once a while back an issue with loading an fob from one client to client db. I think I had different version or build. Theirs was W1 and I had US version. I had to change the date field format in text file and it imported fine into their db and compiled it.