>>>Thank you I will have a look at it.
>>
>>The rule-of-thumb is to use about two more bytes on SQL as compared to dbf, so n(11,2) should be at least decimal(13,2).
>
>Dragan, what I mean is that in VFP N () is bogus.
>It's stored as a decimal, but as soon as is used to make a calculation, It is converted to float.
>Conversely in SQL and .Net, the decimal makes calculations as decimal.
>It follows that doing calculations in SQL and VFP with Decimal Datatype, can lead to different results.

Actually any number, unless obviously integer (and even then I'm not quite sure) or currency, when copied from a field into a variable, is converted into the IEEE 32-bit float format, with 15.5 significant digits. When I was dealing with the exponential exponential inflation in 1993, the order of totalling values mattered very much - if an interim result had more than 15 digits (and we did have 19 at times), anything to the right of the 15th would be zero. So if you had two numbers with 18 digits which cancel each other and then add the third with just 6 digits, everything's alright, because the result after first addition is zero. If you add a 6 digit number first and then add the negative 18 digit number, your result is truncated to thousands.

The other trouble with Fox's N(i,d) numbers is the habit, inherited from dBase, to store as much as possible, because it's actually an ASCII representation of the number, not any binary format. So in a N(6,2) field, which should hold numbers like 123.45, you can actually store 1234.5 and even 123456 and it won't break. But it will break the conversion into SQL if you don't allow for these possible larger numbers that it fit into six digits.

CREATE CURSOR xx (n n(6,3))
INSERT into xx value (123.45)
INSERT into xx value (1234.5)
INSERT into xx value (12345)
INSERT into xx value (123456)
BROWSE