3

If I have a table in SQL 2008 R2 with a nullable column of type Decimal(35,18) and pull that into the edmx. The largest decimal value I can successfully save to the DB without getting a Conversion Overflows error is

79,228,162,514

This is very odd as this matches the upper bounds of Decimal (if you compare digits not in actual value)

http://msdn.microsoft.com/en-us/library/system.decimal.maxvalue.aspx

79,228,162,514,264,337,593,543,950,335

However I am not even close to the max 28 digits.

I filed a bug as I believe it is... but I can't believe it is as this would be a HUGE issue?

http://entityframework.codeplex.com/workitem/522

AndyBufNY
  • 238
  • 2
  • 11
  • Figured out a little big more on this. What seems to actually be happening is if you take the decimal.MaxValue of 79,228,162,514,264,337,593,543,950,335 and made it a string and this did .Substring(0,28 - Scale) that would be the max value being used So if in the DB you had a scale of 18 it would be maxvalue = "79,228,162,514,264,337,593,543,950,335".Substring(0, 28 - scale) instead of allowing 999,999 etc for each level of precision. – AndyBufNY Sep 18 '12 at 19:22
  • As Andriy said, this is by design and is a flaw in your understanding of how it works. This is why you probably shouldn't file bug reports unless you are certain it is a bug. So now you've created extra work for the program managers and testers who have to figure out that it's not a bug at all. – Erik Funkenbusch Oct 08 '12 at 21:02

1 Answers1

1

This is by design.

You specified scale 18 so 79,228,162,514 is interpreted and stored as 79,228,162,514,000,000,000,000,000,000 x 10^-18

If you increase the integer part any more it will be bigger than the CLR decimal MaxValue 79,228,162,514,264,337,593,543,950,335

Andriy Svyryd
  • 2,021
  • 1
  • 19
  • 26