>>The difference is that a single = acts as specified by your EXACT setting while == demands an exact match regardless of SET EXACT.
>
>Thanks guys!! I had a feeling it was something like that (the == being "more" exacting) but couldn't find anything to support that.
>
>What's really wierd is that it finds some but not other instances of the district. I did a select distinct and the only "PE" one in there is "PE" ... only one record returned for the select distinct. So if it found 15 of them, and they were all the same, wonder why it didn't find all of them. Really strange.
>
>Oh, well... I guess the answer at this point is to switch the "offending" == to = and see if that makes it okay. I know it does for the guy that called, but I have to make sure it doesn't break the system for someone else :)
>
>As always, thanks for the help.

The answer actually is not so simple. Firslty, SELECT-SQL ruled not by SET EXACT but by SET ANSI setting, which works pretty much the same way. Also, note that using either SET ANSI ON, or == in SELECT_SQL where clause may significantly reduce performance of your queries. So, the best way is to design your data/interface the way so SET ANSI OFF and = in SELECT_SQL will be sufficient.