> >?? I use WHERE clauses on SSPs all the time. There can be, and it works
> >from the server,
>
> I meant to comment that using WHERE clauses on SSPs is a really naf
> idea. If you want filtering on a virtual table, you use the procedure
> itself to restrict the set, by passing your limiting criteria in
> the input
> parameters. Otherwise, the SP has to generate every row that the SP is
> capable of generating and then screen each row as it is output.
>
> The *right* (read quick, responsive, low-calorie) way to do this is to
> define SPs that have the "where" criteria in the input params and
> then use
> those inside the SP to select the rows. This way, the SP handles
> only the
> data the client actually wants AND it can use indexes. Same story with
> ordering criteria, if you can manage to live without OrderingItems, et al.
>
> Helen

I'm aware of this but while I'm developing, I do not want to create many
versions of the essentially the same SSP. I would rather expand the one SSP
until I know what is required, then I may make hybrids to increase
performance. Luckily at this stage, the SP is not slow. It's easier to go
back later and remove WHERE clauses and replace SSP names or params than
have multiple SSPs and have to manage the resultset for every one of them
each time I add a field.
Alan