Hi,
If the total should be around 8180 and you got around 8990, I suspect
you use a join and one of the table has duplicated values (in a column
implied in the join). That duplicated value duplicate some record of the
table supplying amounts to be summed, and generate the error.
If the error is about why 0.8 may end up being represented by
0.80000000....0001, that is due the the IEEE representation of a floating
point number: they are, by nature, approximative, because they can only
represent, exactly, only a sum of power of 2. For illustration:
0.1b or 2^-1 or 0.5
0.01b or 2^-2 or 0.25
0.11b or 2^-1 + 2^-2 or 0.75
(the first column is a kind of decimal representation, but not 1/10, 1/100,
etc, but 1/2, 1/4, 1/8, ... ; the last column is in base 10, as usual)
are three cases where the conversion are all exacts, but try with
0.8 = 0.5 + 0.25 + 0.03125 + 0.015625 + ...
= 2^-1 2^-2 2^-5 + 2^-6 + ...
= 0.110011b...
shows that even with 6 bits, we are still unable to exactly represent 0.8
(base 10) ... and you can continue to add more and more bits, you are still
supplying only an approximation. We end up with two possible representation,
one lower and one higher. For a case we were limited to 6 bits, with 0.8, we
got 0.110011b which is under 0.8 ( 0.796875), and 0.110100b, or 2^-1 +
2^-2 + 2^-4, lightly higher than 0.8 (0.8125). The representation with the
least error would be keep,so, in general, you can end up with
0.800000000...01, or with 0.79999...99 as INTERNAL representation. Keeping
two decimal digits for display is just for that, for display, for output,
cosmetic, appearance, when the data type is a float, or a double. You know
that appearance is just than, not often the REAL stuff...
On the other hand, a Decimal number is said "exact" in that, if the number
is inside a specified range, the decimal number will be exactly represented,
in memory. 0.8 can be exactly represented in a Decimal data type, because
the number is "scaled up", here by a factor of 10, to become an integer, 8,
and an integer is exactly representible and in base 10, and in base 2,
without any error occuring between the conversion from one base to the
other.
Hoping it may help,
Vanderghast, Access MVP
