At 02:28 PM 7/09/2004 +0000, you wrote:

>Thanks for the advice Helen. Not entirely sure what you mean by this
>though:
>
> > What you can do is call the selectable procedure with an ORDER BY
>clause
> > and a WHERE clause, if you don't want to do the WHERE via
>parameters. It's
> > slow on the server side, since the entire procedure will have to
>execute
> > before the sorting can begin, but it might be acceptable if the
>unmodified
> > output set is small.
>
>Do you mean to perform a select from the SP (much like a view) whilst
>specifying the where/order clauses? If so, yes, I can see why this
>would be slow.

Yes.

>As a general rule though, SPs are more efficient than performing the
>query directly from the client yes?

No, that's not the rule. Where SP's provide speed benefits is to do
processing on sets that direct DSQL can't do, or can only do ineffectively
(like, for example, multiple correlated subqueries on one or several
"lookup" tables). IMO, it's nonsense to use SPs for queries that don't need
them.

>I think, as you suggested, I will go with the view option in this
>case. I was trying to restrict client access to the db through the use
>of SPs only but a view seems a good compromise given the requirements.

Views are ideal for restricting access. Can-openers are much better for
opening bean-cans - use the screwdriver on the paint tin.

./heLen