>>>>>VFP doesn't do 64 bit integers. If such a number is encountered, it is automatically converted as IEEE float, with standard 15,5 significant digits.
>>>>
>>>Are you certain? AFAIR Currency mangles 8byte signed integers internally...
>>>
>
>>>>A follow up question, if you don't mind. Does it mean then, when using SQL Server as database for VFP application, using the Bigint type column does not make much sense? Since VFP only uses 32 bit integers.
>>>
>>>
>>>See above. Also mapping into Strings is possible, if needed for keys for instance.
>>
>>As I mentioned to Dragan, I was using Bigint in SQL Server because I though would be able to have up to 64 Bittest() values. But since Bittest() only supports 32 bit integers, other options are simply not applicable.
>
>The embolded sentence tickled me into responding... As written it is just false.
>Even if you had written "Since VFP bithandling only uses 32 bit integers:
>while vfp Bit-functons force the parameter into an int4, if you have a real need/use case for persisting more flags reached via an index, you can persist into other data types and create functions isolating the correct int4 and feed that to bitfunctions. In the unlikely case of running into speed problems, persisting into string and writing the above mentioned function as a C dll/fll will give a solid boost.

Ok