>
> At the moment, that can't work because all dynamic statements in
> procedures use the clients privileges. In a future version, it will be
> possible to change that rule - exactly how is under discussion.
> However, procedures that blindly execute full statements passed on from
> the client should not execute those statements with special

privileges -

> for obvious reasons.
>
>
> Regards,
>
>
> Ann

Ann

Thanks for taking the time to explain the issues with the EXECUTE
STATEMENT approach: it's helpful to understand the background.

Yes, I have already experienced building SPs with hugh sets of IF NULL
..etc. as you say catering for all the permutations & combinations of
selections of, in my case, database filter choices; it's not ideal
because you have to draw a limit somewhere on the user's number of
choices.

I have also passed whole WHERE clauses into SQL string variables for
use in EXECUTE STATEMENT, although I have had a problem in specifying
more than one column for the output - see my earlier post 60610 for
what I'm referring to. If you have any further thoughts on this latter
problem I would be very grateful to hear them!

Many thanks to all the contributors to this thread - it's been very
helpful indeed.

Will