Sql Server Truncates Decimal Points Of A Newly Created Field In A View
Solution 1:
If you want something like decimal(38,16) then you need to cast the inputs not the output after truncation has already occurred!
SELECT CAST(6.71ASDECIMAL(38,18))/3.41AS NewNumber
Returns
1.9677419354838709
Check the datatype
SELECT
SQL_VARIANT_PROPERTY(CAST(6.71ASDECIMAL(38,18))/3.41, 'BaseType'),
SQL_VARIANT_PROPERTY(CAST(6.71ASDECIMAL(38,18))/3.41, 'Precision'),
SQL_VARIANT_PROPERTY(CAST(6.71ASDECIMAL(38,18))/3.41, 'Scale')
Returns
numeric3816Edit
This is just to add an additional link as follow up to the comments. The rules for decimal to decimal conversion are described in BOL. That link includes the following phrase
*The result precision and scale have an absolute maximum of 38. When a result precision is greater than 38, the corresponding scale is reduced to prevent the integral part of a result from being truncated.
but leaves it unspecified exactly how such truncation is performed. This is documented here.
Solution 2:
This is a bit workaround, but I think it's worth a note.
select ((6.71*10000)/(3.41*10000)) as NewNumber
This query:
SELECT6.71/3.41, ((6.71*1000000)/(3.41*1000000)) as NewNumber
returns:
1.967741 1.96774193548387
Solution 3:
The literal 6.71 is treated as a numeric which has a fixed precision. Since you're doing division, you're changing the number of decimal places, which is not something you want to be using when accuracy is paramount. If you want to treat your numbers like they're accurate, you need to cast the denominator in your query to be a decimal data type with a larger precision. This should work for you:
select6.71 / cast(3.41asdecimal(18, 8)) as NewNumber
Post a Comment for "Sql Server Truncates Decimal Points Of A Newly Created Field In A View"