NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/database/ingres/2378

Text File | 1993-01-28 | 3.9 KB | 93 lines

Newsgroups: comp.databases.ingres
Path: sparky!uunet!tpghq!sfc
From: [e-mail] (Steve Caswell)
Subject: Re: Ingres error handling
Message-ID: <[e-mail]>
Organization: Palmer & Associates, Inc., Norcross, GA
References: <[e-mail]>
Date: Thu, 28 Jan 1993 14:31:55 GMT
Lines: 82

In article <[e-mail]> [e-mail] (Thomas J Lohman) writes:
>I am having some difficulty unearthing all of the different ways
>you can trap Ingres EQUEL/ESQL errors for the C language.
>
>I will try to summarize my thoughts and would like people to tell me
>how they think it works (I am most likely wrong anyhow).
>
>Ways to capture/get errors in EQUEL
>-----------------------------------
>
>(1) Use the IIseterr function to define an error handler which will be
>    called by Ingres if there is an Ingres error.
>
>(2) Issue the inquire_ingres (inquire_equel) command to find out the
>    error number and deal with it.  This option would have to be used
>    in a case by case basis.
>
>Now, my question is, will option (2) suppress msgs going to stdout, unless
>I explicitly tell it to output error messages?
>
>Ways to capture/get errors in ESQL
>-----------------------------------
>
>(1) Declare the SQLCA structure, and check the sqlcode member in a case
>    by case basis.
>
>(2) Declare the SQLCA structure and use the "whenever" statement deal with
>    warnings, or errors.  This also enables you to call your a user
>    defined function, and it is only valid for the SQL statements which follow
>    it's definition inside the source module.
>
>(3) Define an error trapping routine which can then be set using the
>    set_sql command. I think that the SQLCA shouldn't be defined.
>
>(4) You can use the inquire_sql statement to find out the error, although
>    it does say this does not suppress messages to the screen.
>
>(5) You can use the IIseterr function, like above.
>
>
>SQL seems to have more variety but the documentation doesn't really
>do a great job of defining what you can do.  It seems that under ESQL,
>option (1) should really be used as well as option (2).  Option (3)
>seems to the equivalent of (5) which seems to be the equivalent of
>EQUEL's option (1).
>
>I would like to know what I've screwed up in the above ramblings, and
>I'd be interested in knowing how people handle error checking in
>ESQL especially for C.
>
>thanks,
>
>
>--tom
>
Error handling in INGRES applications can be a complex task.  In fact, I've
seen applications where the developers spent as much time on the error handling
as with anything else in the app.  You are correct that ESQL gives you more
options, but along with those options comes more things to consider.  In our
application development, we primarily use the WHENEVER directive to call a
general error handler package that we have written.  This error handler takes
care of writing to log files, sending mail, etc., as well as setting some
flags the program can then look at and decide what action to take.  On
certain types of errors, the error handler will simply stop the program, but
that is also tunable.

We use the WHENEVER directive approach because it lets us concentrate more
on the real functionality of the application.  The developer doesn't have
to worry about remembering to put in the call to inquire_ingres.

Option (3) may not be a good solution if you want the error handler to do
automatic rollback/commits, because no database statement is allowed to be
executed from the error handler routine.

I don't really think there is a "right way" or "wrong way" to do error handling,as long as you are doing it.  The only "wrong way" is to not do any.


--

Steve Caswell           |   [phone]    |  "The opinions expressed are my
Principal Consultant    |   [e-mail]     |   own.  They may not be perfect,
The Palmer Group        |   uunet!tpghq!sfc   |   but they're all I've got."