>>>>>>>>>>Any help ?
>>>>>>>>>
>>>>>>>>>Have you tried N(33,10) in VFP ?
>>>>>>>>
>>>>>>>>Create table testit (mynumber n(33,10))
>>>>>>>>
>>>>>>>>gives an error that "field width or number of decimal places is invalid"
>>>>>>>>
>>>>>>>>In the table designer the best I can get is 20,9
>>>>>>>>
>>>>>>>>Am I missing some trick?
>>>>>>>
>>>>>>>Sorry, have you tried B(10) ?
>>>>>>
>>>>>>Yes, and B(16)
>>>>>>
>>>>>>Both store 123456789012.12350000
>>>>>
>>>>>Did you check VFP Help Double Type?
>>>>
>>>>Again, yes. Double stores the number as 123456789013
>>>>
>>>>As Al and HIlmar have confirmed what I am seeing is a limitation of VFP.
>>>
>>>Have you tried shifting the decimal point? You could multiply by 100000 to shift the decimal point left for storing and then when retrieving divide back by 100000 for calculations. The number that you multiply/divide is determined by the number of significant digits that you want to maintain.
>>
>>
>>That won't change a thing. Double structure has an exponent and a mantissa which keeps 15.95 significant digits. Multiplying or dividing by a power of 10 has no impact on the mantissa, only on the exponent
>>
>>http://en.wikipedia.org/wiki/Double_precision
>
>Thanks, guys. I'm pretty math impaired. I was thinking that I could use a numeric field for data entry but bind to a textcolumn and have a trigger on the backend translate that to decimal(22,10) Does that sound workable. ?


Dunno - do you use that field to calculate anything ?

If not - leave it as text/string - use a RegEx to validate the input

As to the trigger question - cannot answer - but if possible - I think you need two fields - or maybe better, have string field and add a calculated field decimal(22,10). Then you have only the string field to update