>>I use integers in combos all the time, but then the rowsource is practically always fields, i.e. "alias.displayfield,integerkey", and these integers are usually small and surely not negative. I wonder if large negative integers may somehow be out of scope for Fox? I assume the definition of large would be "negative with the 31st bit used". This is not the only place where VFP's definition of integer as "signed 32-bit integer" doesn't really work; it's also when you try to use some APIs which need large unsigned integers (with 31st bit set) that we have problems.
>
>You've got it - VFP's internal integer type is a signed LONG, not a ULONG, so values >2^31-1 in a ULONG are shown as a negative number, and integer numeric values 2^31 and greater are actually stored as an N datatype. This is why I added recasting code using BITOR() to ClsHeap in the last revision, so that passing a value of 0xFFFFFFFF as an INTEGER parameter to a DLL didn't smoke API calls on some OS versions. The range of values supported internally as an integer in VFP range from -2^31 - 2^31-1.
>
>If very large integers are encountered and encoded as reals, they may not be represented internally as an integer value, only as the closest real approximate value in a 4 byte real. As numbers get larger, an entire range of integer values may end up being represented with an identical real - the integers are indistinguishable in a 4 byte real (the numbers supported are larger for a DOUBLE.)
>
>Take a look at the comments in ClsHeap for a more detailed explanation of the representation and conversion..

Exactly the direction where I would dig into if/when I'd have this problem. But then, knowing this can happen, I'm not even walking into that direction if I can avoid it... and did that with success so far.

Don't know how this helps Steve, though, because these large negative integers seem to be there for some other reason, so I don't know if he's allowed to replace them with some tame numbers.

BTW, I thought VFP was keeping N type numbers with more than 4 bytes internally, since its precision is 15.5 significant digits. Or is this conversion of long integer into short real taking place only in some special cases?