>>>>Try setting ANSI and EXACT ON before the select, and remove the "==" and see what happens.
>>>
>>>SET EXACT has no effect on SQL commands and "==" is the same as SET ANSI ON.
>>
>>I refer you to page 130 of Tamar's Taming SQL and the example of "Smith = S" and the effect of SET EXACT OFF, with SET EXACT OFF the results may not be what you expect.
>>
>
>First, thanks for all the kind words about the book.
>
>As for SET EXACT, here's the quote from the book:
>[quote]
>VFP has an unusual way of comparing strings. When SET EXACT is OFF, strings are compared only to the end of the right-hand string. That means that, in Xbase code, the first comparison here is True, while the second is False:
>
>"Smith" = "S"
>"S" = "Smith"
>
>This is convenient for doing look-ups and so forth, though it’s also one of those traps VFP developers fall into regularly.
>
>SQL commands are not affected by SET EXACT. However, the SET ANSI command has a similar impact on them. SET ANSI OFF allows partial string matching in SQL commands.
>[/quote]
>
>Note that I say clearly that SET EXACT doesn't affect SQL commands.
>
>That said, I do seem to recall that in at least one version of FoxPro, having SET EXACT and SET ANSI set differently could slow things down. But I don't think that's still true.
>
>Tamar

Once I got this effect, many years ago, and I was so scared :), that I adopted strict policy: any application runs under
Set Exact On
Set Ansi Off
and if exact match is required in SQL then I could use '==' there, though by another strict rule I use integer keys (for table joins), or for rarer occasion fixed-length character keys.