Repository navigation
Decimal Conversion Overflow For Decimal 38,18 #550
Description
When using a decimal column defined as DECIMAL(38,18) in SQL Server 2014 with Entity Framework 6.1.3 (and 6.2.0), we are unable to save the following amount:
233275179263.0
This results in a "conversion overflows" exception message when attempting to call context.SaveChanges(). From what I can tell, this is a valid decimal and can be stored in SQL Server (as I inserted it manually to verify its a valid decimal). DECIMAL(38,18) should allow 38 digits, with 18 of them being to the right of the decimal point.
If we change the column to DECIMAL(38,16) this value stores without any issue. Why does this occur?
I unfortunately cannot provide code examples or detailed stack traces due to our corporate policy.
Further technical details
EF version: 6.1.3, replicated with 6.2.0
Database Provider: EntityFramework.SqlServer, SQL Server 2014
.NET Framework: 4.5
Operating system: Windows 10 with IIS Express 10, Windows Server 2008R2 with IIS 7.5
IDE: Visual Studio 2017 15.7.3
Activity
Noksa commentedon Aug 3, 2018
Same issue, but with decimal (38, 20). :(
ajcvickers commentedon Mar 18, 2019
EF Team Triage: This issue is lacking enough information for us to be able to effectively triage it. In particular, it is missing the following information requested in the new issue template. Can you please provide this information?
Ideally include a complete code listing that we can run to reproduce the issue.
Alternatively, you can provide a project/solution that we can run.
BTW we're not just doing this to be mean 😄... we get a lot traffic on this project and it takes time to attempt to reproduce an issue based on fragments of information. In addition, our attempt is often unsuccessful as the exact conditions required to hit the issue are often not explicitly included in the code provided. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we ask that folks give us a self-contained way to reproduce an issue.
For a guide on submitting good bug reports, read Painless Bug Tracking.
BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.
ajcvickers commentedon Jun 26, 2019
EF Team Triage: Closing this issue as the requested additional details have not been provided and we have been unable to reproduce it.
BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.