SQL server real field converts my numbers into normal format
I store some numbers in a 'real' type field.
I insert/read values to/from it from my c# application usin开发者_高级运维g ADO.net. When I query my data in Server Management Studio I can see it converts my numbers into scientific normal format, like: 2,211221E+07. I did not set anythig to do this, everything is default.
How can I avoid this behaviour?
MS SQL Server 2008 Express/.Net 4/VS2010
It doesn't convert your reals (IEEE floating points) into scientific format: that's how it displays them in SSMS. Here's how ADO.Net maps data types between SQL Server and the .Net world: http://msdn.microsoft.com/en-us/library/cc716729.aspx
For floating point types, SQL Server implements the ISO data type float(
n)
, where n is the size of the mantissa in bits (1-53 inclusive). real
is a synonym for float(24)
; float
is a synonym for float(53)
.
Rather as you might expect, floating point columns with a mantissa 1-24 bits in size are mapped to/from System.Single
; whilst those with mantissa more than 24 bits in size are mapped to System.Double
.
Sql Server's money
and smallmoney
data types really have little to do with money. They are just fixed-precision decimals, with a precision of 4 decimal places (1/10000 of a unit). Ado.Net maps money
and smallmoney
to System.Decimal
and maps System.Decimal
to money
(there is no mapping to smallmoney
). This conversion suffers from something of an impedance mismatch, however, System.Decimal
being a decimal floating point format. The conversion to/from SQL Server's money
datatype can result in
- Loss of precision. If the
System.Decimal
value has more than 4 digits to the right of the decimal point, the extra digits are lost. - Gain of precision. If the `System.Decimal value has less than 4 digits to the right of the decimal point, in the conversion to money, it gains precision in the form of extra digits (trialing zeros) to the right of the decimal point. That extra precision is maintained when it it read back from SQL Server.
精彩评论