>>>Calvin,
>>>
>>>According the the VFP5 help file:
>>>
>>>If you specify more than four decimal places in a currency expression, Visual FoxPro rounds to four places before evaluating the expression.
>>>
>>>So it's working as documented the 0.41116 is being rounded to 0.4112 before the expression is evaluated. You may have to take the currency numeric to get the precision you need during the operation.
>>>
>>>snip...
>
>>Another case of failing to RTFM...just be glad we're not doing C - I'm in working today because someone failed to properly cast some pointers to structures before doing some (in theory) simple pointer math....
>
>
>Well Ed, I reckon just because it works like the manual says doesn't make it right. 'Correct' maybe, but not 'right'. Doesn't this mean really that we should avoid the currency type? I do, :-), but for other reasons, like the way it displays in a grid.

From my POV, yes, because of the types of rounding errors that may be accidentally introduced when the precision of an intermediate computation exceeds the precision supported by a currency field. For addition, or even multiplicative, operations where the final precision of a computation uses fewer decimal places than the precision of the currency field, and where rounding forced by reduced precision of the intermediate computation is better than the result of inexact representation due to magnitude of a floating point number, the currency data type is a better choice. I only wish that VFP supported something like a scalable 80 bit BCD type...

IOW, if you need to compute a value with more precision than currency supports, don't use currency. If fixed precision is a bigger issue for you, then currency or another fixed decimal representation is a better choice (there are a whole range of values that would display as .000100, two decimal places better precision than used for currency, that would not all be exactly equal for comparison purposes.) That's the tradeoff in the two representations.

Ed