How You Can Use IIseterr() in Ingres Applications
To implement a user-written Ingres error handler in an Ingres application, follow this step-by-step outline. See Errors That Cannot Be Handled in
Error Handler Restrictions for details about what errors are affected by the error handler.
The following example is written in embedded SQL/C, but you can write it in any other Ingres-supported language. Check the section, Runtime Error Processing, in the Embedded QUEL Companion Guide, for your language for details on how to use IIseterr() in other programming languages. IIseterr() is documented only in the EQUEL guides.
1. Write your error handler routine. This is an embedded SQL routine that receives error numbers as arguments, and contains your custom code for handling errors during the running of the application.
Code your routine to return 0 for any errors you are handling locally. This suppresses the printing of error messages. For other errors, your routine must return the error number received. The error message is then displayed on the screen.
For example, the following routine (named "myhandler") overrides the default error handling for error 4700 (deadlock). Error messages for this error are suppressed—only your 4GL program knows when they happen (via inquire_sql). Error messages for all other errors print on the screen at run time, as usual.
int myhandler (errno)
int *errno;
{
#define DEADLOCK 4700
int status = 0;
switch (*errno)
{
case DEADLOCK:
status = 0; /* suppress message */
break;
default:
status = *errno; /* All other errors:*/
/* print message */
break;
}
return (status);
}
2. Write an embedded SQL routine that calls IIseterr() and passes it the name of your user-written error handler.
For example, the following routine (named "seterr") declares the error handler (named "myhandler") to be used in an Ingres application.
seterr ()
{
extern int myhandler();
IIseterr (myhandler);
return;
}
3. Within your ABF or Vision application, create a procedure for each of the two embedded-SQL routines.
In this example, create procedures named "myhandler" and "seterr."
4. In the initialize section of the application's Top frame, call the routine that declares the user-written error handler. This is the routine that you wrote in step 2.
For example:
/* Top frame of application */
initialize ( ) =
begin
callproc seterr ; /* Do before any */
/* database statements */
statements
end
The application calls the procedure "seterr" when it starts up. The procedure "seterr" tells IIseterr() that the name of the user-written error handler for this application is "myhandler."
After your application calls IIseterr() and passes the name "myhandler," error handling is affected in all frames in the application except embedded SQL procedures. See
Effect on Embedded SQL Procedures.
Last modified date: 08/14/2024