>Edward,
>
>>You may build a cursor on fly with records 'BROO','FOXB' etc and then
>>select town from towns where town IN (select town from mycursor)
>
>Yes, I know. Actually, I was thinking about two possible scenarios here:
>
>1) Create cursors and use subquery the same way as you suggested;
>2) Play with SYS(3055) function to increase complexity level.
>
>Let's me explain the problem, why the first approach is not so straightforward.
>
>I have an application, which should return user's selction via result in Form Unload method (where exp). It also returns JoinCondition, FieldList, etc. through memory variables. The name of this app is BTCrit.
>The other app, which perform the actual SQL, called Querier. The problem is that BTCrit has it's own DS, so all cursors, defined in BTCrit, would be unvisible for Querier.
> So, the first approach requeres the both applications share the same DS.
> Since we're working as a team on the complex project, it should be a team's decision...

In this situation, I would do following:
1. Create properties and property-arrays in calling application (form).
2. Pass object reference to called form.
3. Fill all abovementioned properties in called form destroy event, i.e. 'cursors' will be represented by arrays (you don't have more that 65K selections, correct :).
4. Calling form may process propeety-arrays to cursors and run SQL.

It's not the only way, but I would prefer it just because of general taste.

> BTW, my original question was about VFP limitation in IN function? I'm just curious.

I never use IN with values inside. The reason that some years ago it was a bug on this place and, you know, when you get such a place you don't want to go there anymore :-).