How to get exact value in SQL Server - sql

Question

I am dividing 100000=Amount into 9=Shift into Days=30
But when I need the actual amount so how do I get it?
In SQL:
Declare #R1 as money, #R2 as money, #R3 as money
Set #R1 = 100000 / 9 / 30
Set #R2 = #R1 * 9 * 30
select #R2 As 'ActualAmount'
I need exactly 100,000, but the result is 99900.00 - why?

Answer 1

By default sql will do integer division. Just add *1.0 to make it decimal division
Set #R1=100000*1.0/9/30
SQL DEMO
Use float instead of money
SELECT (100000/9/30)*9*30 result, 'v1' as version
UNION
SELECT (100000*1.0/9/30)*9*30, 'v2'
UNION
SELECT (CAST(100000 as float)/9/30)*9*30, 'v3'
ORDER BY version
OUTPUT

Answer 2

Welcome to the wonderful world of floating point rounding errors. 100000 / 9 = 11111.1111... repeating. Let's simplify the example and pretend we just want 10 / 3; different function, same problem. When 10 / 3 is expressed as a fraction, you could do (10 / 3) * 3, cancel out the threes, and get back to 10. However a computer stores 10 / 3 as 3.33333... repeating, out to as high a precision as it can get. What that precision is, is actually a somewhat complicated question to answer, but suffice it to say, it's not infinity. So what actually gets stored is something like 3.333333....0. When you multiply that by 3, the computer says "ah, you asked me to multiply 3.3333...0 * 3, which is of course 9.99999...0".
Mathematically, your expectation to get 10 back (or in your case, 100,000) is completely reasonable. But because of how a computer stores numbers with repeating decimals, the computer doesn't recognize there's an equivalence between 10 / 3 and 3.33333... (Actually, it sort of does, but the reason it does is probably more to do with luck; more on this later).
As was pointed out in another answer, the reason you're getting 99900 is because it's doing integer division rather than floating point division. So the question then becomes what do you cast 100000 as to get the answer you want?
In your case, float seems to get it right, although it's worth noting that this may not be the case in all circumstances. This probably turns out right because float has 53 decimal places available in its mantissa (significant digits) and with that level of precision, SQL makes an educated guess that you were, in fact, trying to re-form a fraction with infinitely repeating decimal places rather than multiply three numbers very close to, but not quite equal to the original number.
Money on the other hand is usually a bad choice as a data type because it's effectively just a small precision float and leads to problems like this. Decimal also has some problems in this case, as it will actually overshoot the re-formed value.
declare
#Money money = cast(100000 as money) / 2700,
#Float float = cast(100000 as float) / 2700,
#Decimal decimal(38,2) = cast(100000 as decimal(38, 2)) / 2700
select
_Money = #Money,
_MoneyReformed = #Money * 2700,
_Float = #Float,
_FloatReformed = #Float * 2700,
_Decimal = #Decimal,
_DecimalReformed = #Decimal * 2700
If you need a true, universally correct representation of fractions, you'll have to store the numerator and denominator in separate columns so you can manipulate each independently.