That was a great suggestion but soon discovered several limitations as far as ABF-4GL goes (reports cannot use it) :
In my topframe I am setting the maxio to a threshold value by using the 'set maxio' directive and I programm my errorhandler using iiseterr() to trap the error issued when that threshold is reached.
But,as the manual states, 'Your error-handling routine must not issue any database statements in the same session in which the error occurred. If it is necessary to issue database statements in an error handler, open or switch to another session' OR 'Do not issue any
query statements from inside your error handler routine because the application occasionally "hangs" or returns runtime errors.' OR 'User code in the handler cannot issue database statements for the session from which
the handler was called.'
Nor,can I fire a database event,log the error in a table etc
Let's move to "If it is necessary to issue database statements in an error handler, open or switch to another session" part. I connect to a new session where I can issue database statements,do some clean up work,disconnect successfully.
I set the current session as active using
exec sql SET_SQL ( session = :session_id)
before my handler returns and I get a
'Attempt to switch to a non- existent session. (E_LQ00BE) ' error.
The session_id was retrieved by inquire_sql and contains the value '-1' which is the value set by ABF.I must agree that it "does not conform to the rules for session numbers that are stated in the SQL Reference Manual" (quoting a post in comp.database.ingres)
So I thought that because -1 is not the real session id I should retrieve the real session number.
I issued a select dbmsinfo('session_id') inside my topframe and put the return value inside a global variable which is then communicated to my 3GL programm by using 'exec 4gl get global variable'.
However the session id returned by dbmsinfo is a string representation of a hex number ie '0A089EA0' so I had to converted it to an integer inside my Esql/C procedure hence getting the real session id, confirmed by checking the active sessions of the iimonitor's output.
Tried 'exec sql SET_SQL ( session = :session_id)' again with the correct id,but the
'Attempt to switch to a non-existent session. (E_LQ00BE) ' error persisted.
'exec sql connect psnodb session :session_id'
and the error message now is 'Attempt to connect to existing database session 168337056. (E_LQ00BA)'.
It seems like I've run into a dead end because from within the ESQL error handler one cannot use database statements for the current session, nor switch to another session and reconnect back to the old one .