Fabio,

>This does not have some importance with the ruotine of conversion of a literal value.

Yes, it does. 15 digits of precision is 15 digits of precision. You can type a string of digits all day long, but that doesn't mean that VFP or any other language that deals with floating point numbers will store or use the excess digits.

>The ruotine must find the value more close, and must respect the rule that I have written.

No, you must write constants that are within the limits of representation of the datatype. To do otherwise you are only fooling yourself.

create cursor x1 ( i1 i )
insert into x1 values ( 12345678901234567890 )

Is 12345678901234567890 a valid integer constant? Yes it is.

Can it be stored in a 32 bit integer? No it can not.

>This inference does not have logic ( also for integer and currency the range is different ).

It has tremendous logic, sorry that you can't see it. Try this theoretical datatype example

SQL - FabioInt - 43 bit unsigned value

VFP - FabioInt - 54 bit unsigned value

So SQL and VFP have chosen different implementations of the same data type. Every SQL FabioInt can be stored in a VFP FabioInt, but not every VFP FabioInt can be stored in a SQL FabioInt.

>First the SQL range is incomplete.
>Second, for SQL Server the range is:
>±2.22507385850720125967091E-308 to ±1.7976931348623157E+308

I copied my text directly out of the SQL Books Online help file from my install of SQL2000. What topic did you get the alternate values from?

>I think double rapresentation is the same.

Given that the two help files do not list the same range of possible values, then they are not the same.

>If it is not true, VFP not support SQL Server double data type.
>
>For SQL real it is true for VFP, but for SQL Server double also !

Where exactly is it written that VFP8 supports every datatype from SQL server in the exact same bit representation?