At 07:39 PM 16/06/2005, you wrote:

>--- In firebird-support@yahoogroups.com, <buppcpp@y...> wrote:
> > OK, so technically, there is no reason why commit/rollbacks are not
> > supported in SP, it's just a decision that was made not to allow it?
> >
> > Correct?
>
>No,
>
>A SP is just like a query. It must be run from within a transaction.
>It is not the query that gets committed or rolled back, but rather the
> transaction that the query "belongs to".
>
>Think about transactions as being the context by which you understand
>the query. The query does not control the start or end of the transaction.
>
>Whether "save points" become supported in PSQL in the future is
>probably a point for consideration, but it would go against the whole
>architecture of transactions to allow SPs to commit or rollback the
>transaction. Note that you probably don't even need save points in SP
>if your exception handling is done correctly.

The savepoint concept is neatly and properly supported in PSQL and always
has been. Think exception handling. You can create a custom exception for
any condition you like, watch for the condition during execution of a block
and throw the appropriate custom exception. Execution flow then passes
"outward" through the WHEN blocks following each nested block, to the first
possible handler for that exception. Preceding statements in the block
that owns the WHEN statement, or that iteration of that block, if it is a
looper, are "undone". The programmer's control over the logic is very
precise indeed.

./heLen