SPT would let you not only build unlimited numbers of where clauses, but even alter the entire query. You gain total control.

>Hey Mike,
>
>I'll have to tuck that one away in my "tricks" library, but unfortunately it does not address my problem.
>
>I have many 'Views' that use macro-substitution to allow any number of parameters. This has always worked in previous version of VFP, but the intensive SQL changes in VFP 9.0 must have broken this.
>
>I use these generic views more like a stored Query whose parameters are variable. This allows me to have one set of views with an unlimited ability to change the filter at run-time. There is almost no way I could build enough views to handle all the possible paramenters (and each view would have a different name to remember).
>
>For example, if this SQL defined my view:
> Select * from mytable where &vcWhere
>
>I can set the variable "vcWhere" to almost any combination of fields and values to define a filter for my view.
>
>I should probably state why I use "views" and not just code queries into my forms that create updateable cursors. Views have many benefits over coded queries:
>1. Table structure changes - using Stonefield all table structure changes automatically update to my views and I don't have to touch any code.
>2. Views are visual.
>3. Views can participate in database triggers and events.
>4. Generally, things in VFP work better with a View than with a Cursor.
>
>Any other ideas would be greatly appreciated!