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.
>>
>> Yes, I was thinking about creation this custom object, like SQLInfo. The idea of using arrays as properties of this object (BTW, how can you pass back multiple arrays for several cursors - 2-dimensional array, right?) and then massaging them into cursors in calling app seems to be a little combersome...
>> Anyway, I may use this general approach in a fiture, but right now both two apps work, so may be we choose the simplest way to handle this problem - use the same DS for both app (right now they already use the same DS, but it happened because BTCrit creates an ErrorHandler object, which leads to not releasing DS after releasing the form)
>>
>>
>>>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 :-).
>>
>> I see :) As Bret wrote, IN function even could not be used this way. The Error message, which I see, should be 'SQL syntax error' instead of 'SQL command too complex'...
>
>The surprizing note is that it can be used, but very careful... it's a bug there :-).

Now I'm totally confused... Could you please explain more detailed?