I've done something similar to this using about that many parameters. In my case I used the "LIKE" clause a lot - and then I used local views of the remote views. I've heard from others that using local views of remote views is not a good idea - however I've done this for years in a lot of applications and never had a problem.

>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.