>Walter,
>
>
>>How many subqueries can we have in one query? Is there a limitation also?
>>
>>Yep, there is. AFAIK a maximum of 2 subqueries could be used.
>
> Ok, it this case I can not implement SubQuery approach, because in theory I may have more than 2 long lists of selected codes in my app. In real life it's very unusual situation, but it's possible...
> So, I exclude this approach from possible scenarios...
>

I just noticed that if you search the text of VFP help for "subquery", you get topics for error messages specific to subqueries. These topics (1) effectively document the limitations of subqueries and (2) indicate that SQL syntax checking is actually pretty detailed and intelligent, if it works as documented. The Error 1842 topic indicates that subqueries cannot be nested. But that doesn't mean you couldn't have subqueries separated by AND, i.e. ...WHERE field1 IN (SELECT searchfield1 FROM searchtable) AND field2 IN (SELECT searchfield2 FROM searchtable)... and so on. I can imagine such a query getting complicated. Multiple INNER JOINs could be used the same way (if you don't have more than ten, I guess; you said that was a problem).

If you will routinely have users choosing "IN" lists on many fields, you might want to do it in a sequence of queries, each one filtering the previous one on the next field. You could have as many fields as you want, each interim query would not be a complicated SQL statement, and it might even go faster. You would count the number of chosen fields and loop through them from 1 to nFields, creating tempcursor1 to n, and so on.