Let's clear some air. First, as to storage limitations
A DOUBLE stores 64 bits subdivided so that it holds approximately 15 decimal digits and an explicit exponent good to about 10^(+/- 38 - roughly). The decimal point can "float" - which is why it is sometimes called FLOATING POINT instead of REAL. When you store a number containing a fraction, remember that it is a BINARY fraction but we live in a DECIMAL world. Sadly, that decimal world DOES NOT COME OUT EVEN in binary.
Food for thought... perverse beings that we are, if we all were quadradactylic instead of pentadactylic (four-fingered instead of five...), would we have settled on DECIMAL computers as our
de facto standard?
In Access, a DOUBLE is a "native" format for the computer. Fractional numbers that are powers of 2 always come out even on a computer. Numbers that involve denominators with any factors involving decimal numbers 3, 5, or 7 (primes less than 10 OTHER THAN 2) do not - in binary. Since 10 is 2*5, fractions of 10 don't come out even, either. If I recall correctly, 0.1 (decimal) is a
repeating fraction in binary. Something like 0.00011001100110011 ...
So your issue when rounding, fixing, or ... INT'ing, I guess... is that if you had an approximation on your hands, you need to take into account that the number might NEVER be exact - particularly if you are truncating a decimal fraction on a non-decimal machine. This is where adding in a fudge factor might be a real strategy. Like, when computing balances to 0.01, explicitly add or subtract 0.005 before you truncate it. This does, of course, involve lots of math and scaling functions.
The same is not true for Currency. That is a special case because it is what some programming purists call a "cast" - I.e. you cast properties onto it that the underlying storage method really doesn't have. In this case, the cast is to be scaled by 4 decimal places. But it is REALLY a double-long integer. Some systems call this an OCTAWORD. Call it 16 bytes. 128 bits. One bit is the sign leaving 127 bits for the value. The limit on a CURRENCY value is, in essence, numbers ranging +/- (2^7) * (2^120) - then divided by 10,000 (scaled). Now, 2^10 ~ 10^3, so 2^120 ~ 10^36 (before scaling). That comes out to roughly 128 * (10^32) as a first approximation.
In American currency, that means you can count amounts to a tenth of a mil (rare monetary term indeed, since it never bought much in the first place and buys even less now...) for whole dollars up to 128 * (10^32). I don't know the American name for that quantity other than that next year's government spending will probably top that number.
(Supplement: The American version of that number would be named 12.8 DECILLION if I counted it right....)
Since this is a scaled INTEGER, it is always exact to 0.0001 currency units, whether we are talking Euros, Yen, or U.S. Dollars. To use it for simple transactions, just input the correct number including the right number of decimals. BUT remember that if computing tax or interest, you have a couple of digits you cannot usually see acting as guard digits to the right of the last digit you CAN see. And there is where "math artifacts" can creep in. To represent a fraction to fewer digits than are present in the scaled number, you have exactly the same problem with the first number you DIDN'T keep as you would have had with a DOUBLE. So if you choose to convert to CURRENCY from DOUBLE, you won't automagically get rid of all of your problems. You'll just change them to something else.
In the final analysis, you must recognize that any representation has its limits and take into account ways to help the computer find your answer. Each path has its problems and I cannot advise you which way to go. I'll offer this thought... CURRENCY can stay "exact" for whole numbers longer than DOUBLE can... but if your application deals with a 15-digit amount of money, you're doing well anyway.
