At 10:44 PM 6/06/2004 +0000, you wrote:

>You forgot to mention (the in my opinion best article available):
>Jason's ti_ErrorHandling.pdf.

Actually, it's my article. :-)

> >From what I've read now I conclude that ERRCODE is SQLCODE for
>non-errors, and GDSCODE (Interbase numbers) for "real" errors. Right?

Yes and no. Every GDSCODE is grouped under an SQLCODE (and that's the
order in which I've output that errorcode doc, which was built directly
using a SP operating on the internal MSG.GDB). The status array *usually*
returns both the SQLCODE and the GDSCODE. I'm almost certain that, by
checking "Errors Only" in the ib_monitor, you turn off everything except
the GDSCODE.

You can get a very good handle on the contents and meaning of the status
array by studying the help text for TIB_ISCError and TIB_Session's OnError
event. Once you grokk the exception process, it becomes an extremely
powerful tool.

>Thus, if I use IB_MONITOR output strings for error monitoring then
>I must ignore ERRCODE <= 101?

It depends what you are looking for. Jason's DSQL utility in IB_SQL uses
an exception "in reverse": in order to verify that the user is behaving
nicely, he calls a request that will throw an exception if the user is
doing the right thing, and does not throw one if the user is doing the
wrong thing (using the DSQL utility for multi-row selects). The
application watches for the exception and, if it doesn't occur, then the
application will throw its own exception.

In an application you wouldn't be using the IB_Monitor except at design
time. But the monitor output is altogether the wrong place for your apps
to be looking for exception information. If a database exception occurs,
then there is an ISC_Error structure available. You don't get an ISC_Error
if there was no error. The exceptions are listed in reverse order of
occurrence, so the one that finally caused the engine to barf is the first
in the list.

Helen