Skip to main content

Losing precision after multiplication in SQL Server


Yesterday I was doing a little multiplication operation in SQL SERVER. The computation involves multiplication of two decimal numbers. A point to note here is that I've to be very careful while performing the calculations because it's a monetary thing. So, Whatever the calculation made, it must be very accurate such that I shouldn't miss any fractions as it costs in MILLIONS.
The scenario is that I've two numbers, after multiplying each other I'm losing the precision of the values. I've tried to check my database for any faulty data that caused the issue. But the data is absolutely fine.
Here is the sql looks like:

I was surprised to see the result that I've got only got 6 decimal places. What went wrong?
To understand the problem we need to have an idea of the concept called Precision, Scale and Length.The following table depicts that there are few rules to be followed when we are calculating the numeric values or decimal values.
Operation Result precision Result scale *
e1 + e2 max(s1, s2) + max(p1-s1, p2-s2) + 1 max(s1, s2)
e1 - e2 max(s1, s2) + max(p1-s1, p2-s2) + 1 max(s1, s2)
e1 * e2 p1 + p2 + 1 s1 + s2
e1 / e2 p1 - s1 + s2 + max(6, s1 + p2 + 1) max(6, s1 + p2 + 1)
e1 { UNION | EXCEPT | INTERSECT } e2 max(s1, s2) + max(p1-s1, p2-s2) max(s1, s2)
e1 % e2 min(p1-s1, p2 -s2) + max( s1,s2 ) max(s1, s2)
* 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.
For those who don't know what precision and scale is. Precision is the total number of digits and Scale is the number of decimals. Say for example, a data type decimal(10,5). Then the precision is 10 and scale is 5. So for multiplication of two decimal numbers the result precision and the resultant scale as shown as follows: Precision = P1 + P2 +1 = 32 + 32 + 1 = 65
Scale = S1 + S2 = 10 + 10 = 20
Theoretically the result should be of DECIMAL(65,20), but this is INVALID as the maximum capacity of the DECIMAL is 38 only. As the * below the table states, if the result is greater than 38, the corresponding scale is reduced to prevent the integral part of a result from being truncated. So our result precision is greater than 38, SQL server tries to avoid truncating the integral part by reducing the scale, i.e., instead of removing the integer part SQL server will truncate the decimal part. SQL SERVER team has decided to preserve scale of 6 in both division and multiplication scenarios. So our DECIMAL(65,20) is turned into DECIMAL(38,6).
The solution is that we need to minimize the use of precision and scale in the data type that we use such that the resultant precision is not exceeding 38. Now in this case we'll adjust the datatype to get some accuracy in the data.
Now the resultant data type will be DECIMAL(37,20) which is less than the maximum of the decimal's precision limit and hence no implicit reduction is performed.

Comments

Post a Comment

Popular posts from this blog

Hacker Rank: 2D Array - DS Solution

I've been trying to solve the puzzles on HackerRank.com lately. This post is just to solve the problem in Arrays section of Hacker Rank I feel better to solve the problems though. It certainly improves some area in programming language. As I'm a C# developer the problem is solved using C# as programming language. Question: https://www.hackerrank.com/challenges/2d-array And the solution is