There is definitely some kind of limit to the complexity of expressions.

If you want the data for a report, you can use a subquery instead:

select * from MyTable;
  where DEPT in (select DEPT from ValidDepartmentList)

... where the cursor or table ValidDepartmentList would contain, in your example, records with values '0001', '0002' and '0003'.

Other approaches are possible to, including some that can be combined with a SET FILTER.

For instance: Use the same table suggested above, index it on DEPT, go to MyTable, do a SET RELATION (on field DEPT, into the table ValidDepartmentList), and SET FILTER TO NOT EOF("ValidDepartmentList"). If no match is found in the relation, the other table will be at EOF().

HTH,

Hilmar.

>In a VFP6 application that builds a conditional expression used in a SET FILTER... command, I've run into a problem that apparently has to do with the number of OR'ed items in the expression. The expression, which is constructed by the program using data from a table, looks like this: DEPT='0001'.OR.DEPT='0002'.OR.DEPT='0003', etc. The expression is assigned to a variable (e.g., 'cFilterExp') is used to restrict access to another table with the command 'SET FILTER TO &cFilterExp'. All goes well until the expression includes more than 80 '.OR.' clauses. At that point the SET FILTER command causes VFP to fail with error 1308, 'Insufficient stack space'. Is there a way to increase the stack space to keep this from happening? Is there a better way to restrict access to the table? Am I completely misinterpreting this error?
>
>Thanks in advance.
>
>Geof Shuger