Hi Sergey,

This thing reminds me of a scene in David Lynch's 'Wild at Heart', where the guy says to the girl 'I swear the way your mind works is God's own private mystery' or something to that effect.

Whithin it's own warped sense of logic, VFP is of course right:

If we assume a table BigIntTest with one field TestBigInt of type BigInt

and =SQLEXEC(lnHandle,[SELECT * FROM BigIntTest])

? TYPE("TestBigInt") && returns C
? LEN(TestBigInt) && returns 20

After that, it's obvious that inserting any kind of numeric into the field will result in an error.

Looks like a bonafide certified bug to me - how does one report that to Microsoft?


>Hi Peter,
>
>What column type Bigint is converted to when you do select?
>
>>>Would you post the exact error message?
>>>
>>>-Mike
>>
>>Michael,
>>
>>It's pretty terse, up comes one of those little boxes saying "Data type mismatch", "Suspend, Ignore, Cancel" and that's it.
>>
>>From VFP Help:
>>--------------------------------------------------------------------------------
>>
>>Visual FoxPro Reference
>>
>>Data type mismatch (Error 9)
>>An expression is invalid because it is composed of data types that Visual FoxPro cannot evaluate together.
>>
>>You have either specified an inappropriate data type, or the two fields specified in an operation between two tables (such as UPDATE, REPLACE, SET RELATION) did not have the same data type.
>>
>>
>>© 2001 Microsoft Corporation. All rights reserved.
>>
>>--------------------------------------------------------------------------------
>>
>>
>>I have fooled around with it a bit, and it seems if I
>>
>>INSERT INTO MyTable... STR(MyInteger) neither VFP nor SQL Server complain, and the data actually make it into the back-end.
>>
>>Which, all things being equal, is a little weird, to say the least.
>>
>>In the meantime I have resolved that simple Int will most likely be good enough, and redefined the BigInt fields to Int.
>>
>>While the other approach may be a workaround, I'm not comfortable about it.