>>>>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
>>
>>Ok, that's a good technical summary of what's going on. In practice then the everyday developer needs to understand the tradeoff. 'N(16,2)' is going to give generally better results but take up twice the storage space of 'Y'.
>
>Within reason. If your primary issue is adding columns of things together, and you round after each stage of computation, currency is fine where 2 decimal places of representation is adequate, and none of the values require more decimal places of accuracy. IOW, if you're using the 'Y' data type, the value of which is never needed to more than 2 decimals, and you never need to multiply by a number with more than 2 decimal places to the right of the decimal, currency works fine. If you have a result where rounding an operand or a result to the decimal precision of currency causes a problem, then currency is a bad choice. The same would be the case if we had an integer type which, if used in computation, forced all operations to be done with integers. there's nothing inherently wrong with an integer type, it just isn't suited to being used for decimal computation if the operands are coerced to the least precise representation, and decimal fractions or floating point numbers are
>involved.
>
>IOW, know what you have to do, and how your language will behave, before using a feature. I lucked out - I correctly interpreted how currency would behave. Others might not read the docs the same way. I tested to find out what would happen before commiting to using the currency feature.

Well I gotta say one thing, your typing speed must be darn impressive :-).
But seriously, I agree with all that you've said, except that, really it's misleading to call it a currency type when it's only good for add ups. As I replied to Calvin, a common thing to do with currency is to calculate interest rates, which is often expressed to several decimal places of a percent. Therefore we could get serious rounding errors in what you would expect to be everyday calculations with money. I don't want to even think about those devalued currencies being converted back and forward with US$.
Probably enough said.
Regards