>Hi Jos,
>
>>>>In all my years of using VFP I cannot remember ever using a Double type field in a table. Now I need to store numeric values which exceed 10 digits before the decimal point and up to 4 digits after the decimal point giving me a numeric field of 15,4.
>>>
>>>As you are near the vfp limit of precision for numeric data perhaps a switch to currency would be better:
>>>also 8 byte storage, but as it is an 8-byte longlong int with artificial fraction perhaps better suited to your needs.
>>>Depends a lot on what you want to do with it besides table storage ;-)
>>>
>>>regards
>>>
>>>thomas
>>
>>Hi Thomas, my main objective was optimizing disk storage size. The decimal precision requried for this data is definitely not going to be more than 4 digits. The largest value will not be more than 15 digits before the decimal. So a numeric field of 20,4 would handle all values. But this takes much more space than a double field type and hence my question.
>>
>>I did a test on the database and converted my numerics to doubles and the application seems to work just fine. I have also now tested with currency field type and again the app seems ok. I was just checking with the UT to see if there were any special cases I should watch out for / test for just in cases ... ?
>
>numeric precision in vfp is "approx 15 digits". So IMHO double is out, calculating with the fields as well.
>I'd chicken on 20,4 as well and use currency, esp. as the value after decimal point already fits exactly.
>
>my 5$ (argueing for money is better done with more than cents...)
>
>thomas

Thomas, I have decided on double as it is safer in my existing app. I found a "gotcha" with currency which is calculations with currency field type cause type problems which require CAST() to convert. Working with double field type keeps the fields as numeric type.