>
> Certainly that change is applicable to NOT IN (<subquery>)

predicates. NOT IN(<list_of_constants>) never could use an index and
still doesn't.

Yes, I misread the original query.

>
> Even though Richard thinks he has resolved the performance problem

by indexing the zipcode field(s), it doesn't address a worse one: the
use of floating-point values as join criteria or, indeed, any
equivalence search such as the pivot in what he refers to as
"dimensional data". Such keys need to be stored as fixed types to
avoid a (quite unknown) number of false negatives.

Agreed, I have made a similar mistake in Delphi comparing TDateTime
values with '<='. It took quite a while to discover why some of the
'equal' values were failing the test. It would not surprise me if
Excel was also returning the wrong values because of this.

If ZipCode refers to what I believe it does, then using an integer
type field would be far more appropriate.

Adam