I just found this in the knowledge base, article # Q164869. It applies to any collation sequence other than MACHINE and sounds just like the problem you're having.

Also, I would advise anyone using SET COLLATE to check out article # Q176884. It describes a bug that can occur when you join tables on an integer field when COLLATE is not MACHINE. This affects every version of VFP and can be impossible to debug. It doesn't happen if the fields are indexed. It bit me the other day becuase I was joining un-indexed cursors. The article doesn't mention it but the problem also seems to apply to using a subquery like this:

SELECT * ;
  FROM mytable ;
  WHERE mytable.Key IN (SELECT Key FROM mytable2)

>Cetin,
>
>Do you have 5.0a. There was a bug in 5.0 with SET COLLATE TO GENERAL. I'm not sure if it applied to other collation sequences. It seems to me that this has to be a bug. The fact that _tally doesn't match what was returned by the query is very strange.
>
>>Now, this would apply to whom that uses collate sequences.
>>Config.fpw :
>>codepage=1254 && Turkish windows
>>collate=TURKISH
>>
>>-create a table
>>-index on a field
>>-enter some values to that indexed field ie: 5 records all "John Smith"

>>select * from mytable ;
>>  where myfield = "John Smith" &&Displays only one record
>>? _tally   && Prints 0
>>set collate to "MACHINE"
>>select * from mytable ;
>>  where myfield = "John Smith" &&Displays all
>>? _tally   && Prints 5
>>set collate to "TURKISH"
>>* Same as above _tally = 0

So what could I be missing ????
>>Cetin