At 10:42 AM 18-09-02 +0300, you wrote:

>Burak:Start a transaction and create some event, you'll not get the
>event's till you commit the
>transaction.
>I tried this very much.

You will get the events when they occur.

>Burak:
>Can you give me a SP example that handling User Defined Exception with ON
>EXCEPTION statement??

There are examples in the IB Language Reference manual. You can download
that from the IB Phoenix site.

>I want to handle exception and see the message at client side.. for example
>create main procedure XXXX
>begin
> execute procedure y
> execute procedure z
> execute procedure g
> (an exception occured
> 1 I have to see the exception at client side
> 2 procedure L must run after the exception)
> execute procedure L
> execute procedure d
>end

No, that can't happen that you get feedback from an executing procedure
until either it completes sucessfully or it fails.

The details of exceptions are returned in the Error Status array. If an
exception occurs, either
(1) your exception-handling code will "silence" it (by handling the problem
and returning control back to the program) or
(2) the unhandled exception will cause execution to stop right where the
exception occurred and return the exception data to the client

When you call other procedures (or chains of procedures) from your main
procedure nothing is ever committed until, back on the client, your
application tells the transaction to commit.

If your client-side exception-handling receives an error status array with
error data in it, your application can then roll back the transaction -
this will cause everything so far processed by your procedure-chain to be
rolled back.

> > There is a TI sheet on the TechInfo page about exceptionhandling.
>----------------------------------------------------------------------------------------------------
>------------------
>Burak: where is this TI sheet on firebirdsql.org or ibphoenix.com or
>ibobjects site????

On the ibobjects website, of course! www.ibobjects.com/TechInfo.html

> What do you mean by "crashes the SP execution"?
>----------------------------------------------------------------------------------------------------
>-----
>Burak:I mean if an user defined exception occurs SP stops execution and
>exits the SP when not
>handled.
>----------------------------------------------------------------------------------------------------

That is not a "crash" - it is the designed behaviour. A SP (and any SP's
which it calls) forms an atomic unit of work initiated by the client and
completed (committed or rolled back) by the client. If any part of the
task is stopped by an exception, the whole task is considered "ruined" from
the point of view of data integrity, and the engine will not permit
execution to continue unless you handle the exception in such a way that
the engine's "opinion" is overruled. A typical example might be inside a
FOR...SELECT loop where an attempt is made to write a duplicate value to a
key. If you catch this exception, you can handle it in your ON... block,
perhaps adding a line to an error table or log-file.

Don't forget that, during procedure execution, you can use
CURRENT_TIMESTAMP and CURRENT_USER, as well as your user data, to capture
contextual information. You might also like to consider maintaining a
system of run-numbers to help in tracking errors. I've had systems where I
pass a run-number to virtually every procedure, for just this reason.

If it is any comfort to you, Firebird 1.5 is going to make the
transaction_id available as a context variable, though it doesn't assist
you right now.

Helen