-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decimal is truncated when saving multiple records on SQL Server #6538
Comments
@recalde the problem is in your
In particular, the call to Instead you could call As a side note, also notice that Test objects that you just added will get returned by tracking queries on the same context, therefore you won't be able to observe the actual precision and scale with which values got stored in the database unless you query with a separate context instance. I assume this may be the reason you believed the first call to |
Note for Triage: The observed behavior is currently by design but I can see it being confusing. Nonetheless there are several aspects we may consider addressing (not trying to make any judgement on the value or feasibility of any of them at this point, just leaving that for the triage discussion):
|
@divega thank you! I'm going to try to override the column type of our scaffolded code now to see if that fixes it on our side. A couple other questions / comments -
|
@recalde I read you initial post too quickly and I somehow missed that this code was generated by our scaffolding. It does looks like a bug.
I couldn't observe this yesterday when I tried your repro. I ran a query on a separate |
@lajones does this ring a bell? Didn't we fix something like this already? Or was it only for string columns? |
@divega - you're thinking of #4312 which was the interaction between This seems to be another issue about not maintaining the precision and scale for a SQL Server (Note: we should update https://github.com/aspnet/EntityFramework/blob/dev/test/Microsoft.EntityFrameworkCore.SqlServer.Design.FunctionalTests/ReverseEngineering/E2E.sql to have such columns and then update the tests that use it.) |
Thanks for confirming @lajones. Can you think of a simple way to override the behavior as described in the third bullet point at #6538 (comment)? |
@divega yes I just re-ran this test (1) and (2) and confirmed that (1) works correctly, and full decimal precision and scale was confirmed via ssms query not db context, and the truncation only happens when 2 or more rows are included in the same SaveChanges(). However, changing the scaffolded code to HasColumnType("decimal(15, 6)") completely fixes the issue, and verified to be working correctly with 100 records. The difference in behavior between just 1 record and 1+ records is what made tracking back the source of the issue to EF difficult (we couldn't reproduce it in unit tests without targeting multiple rows.)
ssms - SELECT * FROM dbo.Test
|
@divega I think it's more likely we need to do something in We already collect the Precision and Scale info in |
See also #5410 |
@rowanmiller I'm sorry I just noticed that the .sql file in the zip file attached wasn't saved... below is the content the SQL Server 2012 schema, not sure how best to package it, should I update the project to create the schema on a SQL server instance or re-zip with the sql file? -- I didn't try to reproduce on sql express, not sure if its sql server-only?
|
@rowanmiller the first post in the issue has a link to a project. With this SQL script it should be complete. So the database is originally created with the columns with the right precision and scale, but the EF model thinks the store type is just "decimal". It sounds like the part that remains unexplained is how inserting just one record can lead to a different result as inserting two records (no rounding vs. rounding). It sounds like debugging how we create parameters should help. |
@divega Exactly, I'm completely satisfied with the solution (replace-all to add precision to mapping) and a future fix in scaffolding, it just seems very strange to me that we only observed the issue when we SaveChanges() with 2+ records. It seems that could lead to a lot of difficult-to-diagnose defects. |
I haven't done any further investigation with this repro but another issue (#6835) was filed today that explains the difference in behavior between single row updates and multiple row updates: While the precision and scale is never configured in Closing this as a duplicate of the other bug. |
Today I met this bug also. The problem is if you are inserting with 1 record then it works perfectly. But If you insert with more than 2 records then decimal is truncated as reported. I can see in SQL Profiler trace, there are 2 completely different generated SQL scripts. the script generated by 2 record looks more complex by converting to decimal, select from a temp table, so on.. that might cause this issue. Do we have any fixes about this yet? Thanks |
Hi @ajcvickers I am using Scaffolding way from Database. Type in database is decimal(16,2) but Context file generated with only "decimal". Do we fix this issue as title? Thanks |
@sonphnt Change it to decimal(16,2). The reverse engineering issue that creates "decimal" by default will be fixed in an upcoming release. |
@ajcvickers Yes, I have to change it manually now. What is upcoming release will fix this problem, Preview 4? I am thinking to use Preview3 to generate Context file in a temp solution and then copy generated files back to my primary project. But I am not sure if Preview 3 solved this issue. |
@sonphnt I think this is already fixed in EF Core 2.0 preview 2. @smitpatel Can you confirm? |
Verified fixed in |
Steps to reproduce
TestDecimalRounding.zip
The issue
Decimal is rounded from 1.23456 to 1.000000 when multiple rows are saved.
Further technical details
EF Core 1.0.0
.NET 4.6.1
Console Application
Windows 7
VS 2015
SQL Server 2012 RC2
The text was updated successfully, but these errors were encountered: