Subject | Re: Dynamic name in a stored procedure |
---|---|
Author | randallsell |
Post date | 2007-11-15T07:34:42Z |
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> >
I was afraid of that.
names.
situations like this. Essentially, you pass the object name as a
VARCHAR(31) variable and construct your statement by concatenation at
run-time.
It seems to me, and hopefully this is a fair analogy, is that this is
like writing JavaScript code that creates other JavaScript code. Not
exactly a very pure or clean solution.
Let me get back to my end-goal to determine if I am taking the right
approach. My end goal is to have just one stored procedure that all
clients call. It will pass back different results based on who is
logged in (CURRENT_USER). In reality the only real difference is the
WHERE clause. For the FULL access - there is no where clause. For the
limited access I strip things down to a simple condition.
As your book points out, the limitations of using EXECUTE STATEMENT
seems to outstrip its usefulness. But if I don't use this approach, my
only other alternative (that I am aware of) would be to start writing
business logic on the client end.
cheers,
-randall
> There is no "correct SQL syntax" for passing object references asarguments to stored procedures.
I was afraid of that.
>2 views based > on a condiiton. SourceView should have one of two view
> > I'm trying to get my stord procedure to return results from one of
names.
>release notes for EXECUTE STATEMENT. It was implemented for
> There is a way to do this. Study the documentation in the v.1.5
situations like this. Essentially, you pass the object name as a
VARCHAR(31) variable and construct your statement by concatenation at
run-time.
It seems to me, and hopefully this is a fair analogy, is that this is
like writing JavaScript code that creates other JavaScript code. Not
exactly a very pure or clean solution.
Let me get back to my end-goal to determine if I am taking the right
approach. My end goal is to have just one stored procedure that all
clients call. It will pass back different results based on who is
logged in (CURRENT_USER). In reality the only real difference is the
WHERE clause. For the FULL access - there is no where clause. For the
limited access I strip things down to a simple condition.
As your book points out, the limitations of using EXECUTE STATEMENT
seems to outstrip its usefulness. But if I don't use this approach, my
only other alternative (that I am aware of) would be to start writing
business logic on the client end.
cheers,
-randall