Fabio,

>On my SQL version 8.00.760(SP3) i haven't invalid values.

The point was that 9 of the literal values are not stored as you requested them to be stored. All of the items in my post flagged by -- invalid value are literals that are out of range for the data type. So you should make the same bug claim against SQL that you are making against VFP.

>........Avoid using float or real columns in WHERE clause search conditions, especially the = and <> operators. It is best to limit float and real columns to > or < comparisons.
>
>You known only this concept ?

Fabio, I don't know if you mean this as the insult that it is or not. Perhaps what you are trying to say doesn't translate well from Italian to English.

But yes, if this was the only concept that I know, then I understand how to use floating point values in digital computers a couple of orders of magnitude better than you.

>I'm curious as to why, now, you ignore the your majour argument:
>VFP and SQL Server uses different fp storage format.

I posted in my first reply in this thread that SQL and VFP have different floating point ranges. You posted back a document that shows where the two different ranges come from. I thought that meant that you finally understood the differences.

>-- surprise result is 4.9406564584124654E-324

No suprise, the SQL documentation doesn't discuss the floating point numbers closest to 0 that it supports, it only discusses the floating point numbers farthest from 0 that it supports. I've not specifically tested the 0 endpoint of values in SQL. Frankly it's not worth my time.

To put some perspective on your 15 significant digit values, by the time you can measure the current wind speed at Marostica in km/hr accurate to the nearest 10 picometers/picosecond 32 bit CPUs will be long out of vogue and we'll be using at least 64 bit CPUs and 128bit floating point numbers.