Also a factor that the view parameters could change frequently as the user presses various filter combinations,
>Hi Tuvia,
>
>I would :
>1/ build these views with a prg rather than the designer
>2/ use filter conditions such as
>

> ... where (isnull(?oFilter.crit1) or crit1 <operator> ?oFilter.crit1) and  (isnull(?oFilter.crit2) or crit2 <operator> ?oFilter.crit2)
>

>3/ store filter values in an object oFilter of class empty - any .null. crit is ignored
>
>
>>We have several large SQL Server tables. The user can view the records unfiltered in a grid (we bring down additional records as the user advances to the next page in the grid.)
>>
>>But here is the issue: the user can also access a "filter" panel and combine filter values for perhaps 10 different fields in that grid's view. The user can specify a value for each of those 10, or no value, so that there can be any combination of specified or "all" within the 10 different filter choices. Once the user selects the filter choices, the grid should update to reflect only those filtered records.
>>
>>There are some restrictions. We have an almost inviolate need to use remote views over sql passthru. We must allow the "all" option for each of the 10 choices.
>>
>>The question is how to best design this. Remote view with 10 parameters? Ugh. Cursors derived from remote views, but then we have to update cursors and the underlying views? Or something else? Rather than specify what we have tried so far, I would rather hear your unbiased opinions.
>>
>>I humbly await your advice.