Once again Ed, I agree (is there a pattern developing here?)

I just wanted to point out the availability of the currency type because although it does not have the magniutude the Cemal specified in his original question, it does have a pretty good range. My (WA) guess was that he was testing the limits several orders of magnitude higher than the actual requirements and if that was the case, then perhaps the currency type might be applicable.

BTW, do you reckon I should submit a doc bug to the fox team - the docs are out by $0.02 in $900,000,000,000,000 !

Cheers,

Andrew

>
>As long as you add and subtract large currency types, you're OK. If he's really talking numbers that big he showed a problem with 18 digits to the left of the decimal, dropping precision after 16 decimal positions, OK, but multiplication/division operations on currency values this large are not reliable. Percentages used in annual interest calculations will exceed the precision of the representation. Daily calculations make your life unpleasant at best.
>
>Don't try to shoehorn in accounting. VFP is the wrong tool here. I'd gladly give up VFP for a nice, big 12-16 byte packed BCD data type and not worry about rounding. YMMV. I go to jail if my accounting is wrong. I don't want to end up in a Turkish jail because I made a bad choice of tool.
>
>>By the way, the largest value I could get VFP to accept as a currency type (using NTOM()) was 922,337,203,685,477.5625