>>This is interesting, I didnt even think of using IN. Problem is though for now, any code I write that has to be run on regular basis has to be supported by my FPW 2.6 App. Using IN clause in 2.6 is only supported for a value set. But thanks for the advice, I will look at using this tip when I replace the 2.6 Reporting System App with my VFP 5.0 Data Warehousing App.
>
>Is there any difference for IN between 2.6 and 5.0 that I'm not aware of?
>
>Vlad

In 2.6, IN cluase can only be used similiar to INLIST().
Ex: SELECT * FROM azhandle WHERE stype IN (VALUE1,VALUE2,VALUE3)

But now with VFP 5.0, IN has 2 uses... it supports the above syntax to limit a field to a hardcoded value set, and to define a subquery to supply a set of values(like you and Ed showed me how to use). Personally, I tend to think in 2.6 mode since I still spend most of my day supporting it. This is why it hadnt occured to me to try using IN when in need of a subquery until you & Ed mentioned it.

To be honest though, I think the fact that I'm using 3 large tables in this example is what is making the difference. I have other situations where I filter down a large table with a smaller one (less than 100 records), and when I get time I'm going to test EXISTS vs IN with that type of work and see if the results are different. Thanks again Vlad, your insights were a big help! :D)