>I'm sorry I thought the problem was with the _TALLY variable. The problem you are experiencing could be.
>1) an corrupt index isue
>2) set exact on/set exact off
>3) Changing the collate causes your records to change order. Some characters are higher in rank then others, by changing the collate you change the rank on some characters, maybe that's where foxpro has problems handling his query.
>You should try and set the rushmore optimization off and see what the result is there. If it is solved now you know that your index could be the problem here, if you create an index in collate turkish and you create one in collate machine you would probably end up with two different indexes that only work in their specific collate setting, if you use them in the other you can get weird results I guess. You could try doing some experimenting here. This is all theory I don't have any experience with the set collate command.
Jeroen,
Thanks and nothing to be sorry about. For you are nonUS, one day you might try to use "collate" also (this was my first attempt after many years living w/o it). As others told me, this has been somewhat documented in a KB article and as Jose said it seems to be fixed in SP3 (I have SP2). FYI details of the problem :
1) It occurs with every index created with collate sequence (only tried Turkish).
2) Set exact has no effect on it.
3) No special chars used in searches (ie: "Adam") but query returns only one record at all times (no wrong SQL, it's the basic and simpliest SQL - ie: select * from mytable where name = "Adam" - no code before or after, this is tested directly from command window). Immediately after setting "set collate to machine", the same SQL returns all records as expected, "set collate to 'TURKISH'" and again only one record (this occurs when where clause has an expression with an index therefore disabling Rushmore should resolve it but it's not something I wanna to do, instead I change collate setting before query and restore after query).
4) Before w/o collate sequence using, my workaround was to change the char with chr(asc(char)-1)+"zz" (ie: our sequence is ...C,Ç,D... so "Ç" becomes "CZZ" when indexing). Only drawback was I should always provide the indexing UDF, capture QBF for those fields and apply the conversion before search, and index file is slightly bigger than it should be).
5) My final decision is to continue using workarounds which are 100% reliable in all versions of Fox.
Thanks for hanging with me on this.
Cetin