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

Well, only that when the ground rules make sense, they make sense...

>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.
>

Yep - I'd be far more comformatable if Cemal needed 14 digit precision, millions, or even 10s of billions - now there's enough play in the format that rounding might not be an issue. I've made the same sort of decision poorly before, because I looked at an annual percentage rate of 8.75%, said, gee, plenty of play there, and promptly lost track of the fact that the daily rate was 1.0875 figured in intervals of 1/364th, losing another 3+ decimal places of precision. And there's the inbred fear of accuracy vs precision that came from too much hard science at an early age.

>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 !
>

I know that you start losing decimal accuracy at between 15 and 16 digit precision with VFP; currency can't scale off of the fixed decimal place, so I think you end up with an 8 byte float of some sort. Christof probably would know off the top of his head...

>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