Subject Re: [IBO] Stored procedure, ExecSQL and Suspend
Author Marco Menardi
--- In IBObjects@y..., Helen Borrie <helebor@t...> wrote:
> At 04:01 PM 02-11-02 +0000, you wrote:
>
>
> 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.

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 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.

mmmm... a lot of things need some clarification, and maybe a GSG update.
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?

>
> In fact, ExecSQL is there just for compatibility with the VCL. Execute()
> is the native IBO method.

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.

>
> >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.

Ok, testing my SP I've discovered that the problem was a bug inside it, so it works without SUSPEND at the end :)

>
> >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.

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.

Thanks a lot!
Marco Menardi