I am working on a test database which requires precision calculations on small numbers. When updating or creating a record, I receive an error indicating a failure - "Unable to create new. ..", or "Unable to update. . .".
A noteworthy line from the output console reads on Create:
dotnet: info
dotnet: : Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]
Executing action method project.Test2.Controllers.Units.UnitTestentriesController.Post (server) with arguments () - Validation state: Invalid
Here's my guess: I found when parsing a number to a string, Javascript will sometimes try to be helpful by using scientific notation. For numbers less than zero, it seems Javascript begins using scientific notation when numbers are less than 0.000001. So, a number like 0.0000001 will convert to "1e-7". I suspect the system is not expecting this. If my assumption is correct, then maybe Number.toFixed() could help solve the problem. Any thoughts? Thank you.
And the OData implementation cannot parse that as a number. Unfortunately I don't think that converting the number to a string via toFixed will help too. OData is strictly checking the types and will complain if it sees a string value where a number is expected. Maybe the only solution is to have an artificial string property and edit it instead and do the mapping in the OnXXXUpdated partial methods in the ODataController.
I have tested a process which seems to work for my application. I decided to try the solution suggested by @korchev to create a text field which can easily submit the user input to the server. I then handle the conversion into a decimal in .NET inside the OnXXXUpdated partial method. In the user interface, I wanted to continue using the number field for user input since it is designed to handle the entry of numbers more easily. When the user clicks the submit button the number is converted to a string using Javascript and stored in the string field. The number field is then set to 0 in order to avoid the oData parse issue. Of course, the number field is repopulated on the server side.
I can't help but think there is a oData configuration setting somewhere which allows for numbers written in scientific notation. . .
It is odd the oData specification does not allow for this. I'm guessing the requirement for a web app to enter numbers with such a high precision is rare. My application is practical, although I must admit the level of precision I'm testing is a bit excessive.
At least there is a work around. Thank you for your effort.
