>Sorry about the delayed answer, but I've been down with the flu.
>
>Have it any way you want, whether it´s VFP or the ODBC driver, in my book it's still a bug, the rest is semantics. The way I see it, we buy a full product that's supposed to let us manipulate data in a SQL Server.
>

You're totally clue-free; VFP doesn't have an equivalent representation. Integers larger than 2^31-1 are represented as a single or double, with an equivalent loss of precision as numbers get larger and the interval between discrete float values increases. Look at the API docs in the on-line help, and the Help File accompanying the ODBC driver, VFPODBC.CHM or VFPODBC.TXT depending on where you got the driver. Also see the reference guides pointed to in the docs for what -precisely- must be supported in order to have a compliant ODBC driver.

RTFM!

>Therefore I expect the ODBC driver / VFP to support the same data types as the back end in a graceful fashion.
>
>Anyway I've filed a bug report as suggested by Sergey, and we'll just have to wait and see
>
>Thank's for your help guys.
>
>
>>This might not be a VFP bug. Remember that VFP access all remote data through ODBC. It may be that ODBC does not know now to handle a 64bit integer.
>>
>>-Mike