>>Yes, but recalling the original thread, it says 'Even if the fields Late, Absent, & Early contain zeros (0.00)...', thus, assuring us that the physical value sitting in the disk is really 0.00.
>>
>>Could numeric field that has 2 decimals can physically contain 0.00000001? Just asking...
>
>Jess,
>
>yes it can. The number in the dbf is stored as a character string but it is converted to an 8 byte floating point number when in memory. If there is a rounding error between the memory variable and the way Fox converts the numeric field you certainly can get 0.00000001 from a numeric field with 2 decimal places that show as 0.00. That's why I use integer fields whenever possible.
>
>The proof is that the IF statement didn't work, meaning either the equal sign is broken or the two numbers are not the same value.
------------
Boy this takes me back... to the days when I hated learning about the hardware... but Jim is right, and results could vary even depending upon the CPU. I recently tested a new CPU that even the manufacturer says does not have the strongest arithmetic unit....

So I guess that means that for things like:
-------------------
MyTable.Counter1 (integer)
MyTable.Counter2 (Numeric 4 0)

REPLACE MyTable.Counter1 WITH 1
REPLACE MyTable.Counter2 WITH 1

DO CASE
CASE MyTable.Counter1 = 1 && is unreliable?
CASE MyTable.Counter2 = 1 && is unreliable?
CASE MyTable.Counter1 > 0 and MyTable.Counter1 < 2 && is reliable?
CASE MyTable.Counter2 > 0 and MyTable.Counter2 < 2 && is reliable?
OTHERWISE && just in case :-)
ENDCASE
-------------------

And if I remember correctly VFP does not handle LARGE numbers as well as it implies (granted in this case zero is not large)... as is illustrated in "Hackers Guide" on page 15...
A numeric field will contain a 20 digit number but Microsoft describes accuracy to 14 or 16 digits....