>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?

>But, in response to Vlad's other message regarding speed, I did some testing.
>
>First off, once Ed helped me with my original queries, seems my job specification was re-written _again_. Below is the final code I used to get this job off my desk:
>
>SELE azactive.offnum, azactive.acct AS account, azactive.name FROM azactive ;
> WHERE NOT EXISTS( ;
> SELE * FROM addunit WHERE addunit.account==azactive.acct) ;
> INTO CURSOR temp1 &&Selects 875 records

Probably you already got the SELECTs with IN, but:

SELE azactive.offnum, azactive.acct AS account, azactive.name FROM azactive ;
WHERE azactive.acct NOT IN ( ;
SELE addunit.account FROM addunit) ;
INTO CURSOR temp1

>SELE azactive.offnum, azactive.acct AS account, azactive.name FROM azactive ;
> WHERE NOT EXISTS( ;
> SELE * FROM azhandle WHERE azhandle.account==azactive.acct) ;
> INTO CURSOR temp2 &&715 records

SELE azactive.offnum, azactive.acct AS account, azactive.name FROM azactive ;
WHERE azactive.acct NOT IN ( ;
SELE azhandle.account FROM azhandle) ;
INTO CURSOR temp2

>SELE * FROM temp1 WHERE EXISTS( ;
> SELE * FROM temp2 WHERE temp2.account==temp1.account) ;
> INTO TABLE azterms &&715 records

SELE * FROM temp1 WHERE temp11.account==temp2.account ;
INTO TABLE azterms

Vlad