Subject | Re: [IBO] Stored procedure, ExecSQL and Suspend |
---|---|
Author | Marco Menardi |
Post date | 2002-11-04T12:57:14Z |
--- In IBObjects@y..., Helen Borrie <helebor@t...> wrote:
Well, of course I use Fields (to be sincere, I use FieldByName, but should work good too, right?) and not Params.
But, as in GSG, I don't do Commit but the values are returned anyway. And, for Queries, if you commit before reading fields value, the query is closed and you don't have nothing to read (CommitAction=caClose)... so Commit should be done before reading return values, *if* must be done?
Thanks a lot!
Marco Menardi
> At 04:01 PM 02-11-02 +0000, you wrote:Firebird documentation says to avoid to use SUSPEND in a non selectable stored procedure ("SUSPEND should not be used in an executable procedure. Use EXIT instead to indicate to the reader explicitly that the statement terminates the procedure.")
>
>
> The SUSPEND won't make any difference on the server side. It *only* takes
> effect at the end of a For...Select..Do loop. In all other cases, it means
> the same thing as EXIT.
>mmmm... a lot of things need some clarification, and maybe a GSG update.
> The server always returns the values in the return parameter block
> following the COMMIT, and IBO reads them in from there. You should read
> them as Fields[], not Params[]. IBO reserves Params[] for input parameters.
Well, of course I use Fields (to be sincere, I use FieldByName, but should work good too, right?) and not Params.
But, as in GSG, I don't do Commit but the values are returned anyway. And, for Queries, if you commit before reading fields value, the query is closed and you don't have nothing to read (CommitAction=caClose)... so Commit should be done before reading return values, *if* must be done?
>Please, eliminate ExecSQL from GSG and eventually IBO samples. GSG is "the Bible" for beginners, so it must be the most right and clear and precise as possible.
> In fact, ExecSQL is there just for compatibility with the VCL. Execute()
> is the native IBO method.
>Ok, testing my SP I've discovered that the problem was a bug inside it, so it works without SUSPEND at the end :)
> >is this EXECUTE PROCEDURE GET_CONTO_DIFFERENZIA_GR in my
> >IB_StoredProcedure to be considered a "select" statement?
>
> No, it is an execute statement and is correct for a SP that does not return
> a dataset.
>Same as above... is Commit really needed? I've tried with a IB_StoredProcedure chained with a transaction with autocommit to false. The code works committing and not committing.
> >What is the general rule?
>
> Use SELECT for a SP that you have defined to return a dataset. This style
> of SP is distinguished by a FOR...SELECT....DO...SUSPEND loop, each
> iteration of which outputs a single row of a dataset.
>
> Use EXECUTE for a SP that performs *anything* except a FOR..SELECT..etc.
>
> Don't design SELECTable SPs that modify data (yes, the engine will let you
> do it but commonsense and ACID rules say "No").
>
> Read output parameters from the Fields[] array AFTER the executable
> procedure's work has been committed.
Thanks a lot!
Marco Menardi