Hi Craig,

>Have you looked at the SET DECIMALS command?

SET DECIMALS bind a format to the variables, calculation is done only on cpu floating point unit.

This original choice done by VFP Team is done for simplified computation and trasformation of a variable ( VFP have only variant variable).

If you write:

x='', VFP alloc 8 bytes for data,
x=$0, VFP alloc 8 bytes
x=DATE(), VFP alloc 8 bytes
x=DATETIME(), VFP alloc 8 bytes
x=.T., VFP alloc 8 bytes
for numeric:
x=1 , VFP alloc 8 bytes, type float64 and format 0 decimals
x=1.0 , VFP alloc 8 bytes, type float64 and format 1 decimals
...

but more bytes is allocate for name,property, etc

DIMENSION x[1], vfp alloc 16 byte, 8 for index and 8 for value ?

If you read a integer field into a variable, it is converted to cpu float64 type,
with output format decimal 0.

If you read a numeric field N(10,3) into a variable, it is converted to cpu float64 type, with output format decimal 3.

If you read a numeric double into a variable, it is not converted,
VFP copied field value and field decimal format.

On VFP a variable is : Name,Data and Output Format

Ken write 50% VFP uses SQL. This is the problem.

The definition of error is: "difference by exact value"

If you calculate all within VFP, you cannot see difference value because
errors is small and identical computation have identical result with identical error, but if you do identical computation within VFP ( on remote view ) and on SQL ( or ORACLE,DB2 ... ) you can get different result.

Canonical example is :

-- VFP
.... compute
IF result<>0
....
ENDIF

-- SQL
.... compute
IF @result<>0
....
ENDIF

With identical data, you can have result zero on SQL, but 1E-13 on VFP;
then program run on different code path ( this is one of the most difficult errors to found, and you found because a your customer has of turns out to you wrong, and has already lost great part of the confidence in your application).

Fabio