Was this helpful?
Errors Originating in Called 3GL Procedures
Many OpenROAD applications call 3GL procedures. If the 4GL calls an Embedded SQL routine that does not switch sessions, the status from the last query issued by the Embedded 3GL routine is available to 4GL. After the 3GL routine returns control to the 4GL, the 4GL can send a user event to a standard error-handling procedure to process the error.
For example, assume that your application uses the SendUserEvent method and a common error-handling procedure to deal with DBMS errors. Assume also that your application calls a 3GL procedure that includes the following Embedded SQL statements:
select ...
exec sql inquire_sql (:dbmserror = dbmserror);
if (dbmserror != 0)
    return;

exec sql insert ...
exec sql inquire_sql (:dbmserror = dbmserror);
if (dbmserror != 0)
    return;
...
When control is returned to the 4GL, the following code fragment obtains the error number returned by the 3GL procedure and uses the SendUserEvent method to send the error number to its 4GL error-handling procedure:
if curframe.dbsession.dbmserror != 0 then
    errorproc.SendUserEvent
        (eventname = '3glerror',
        messagevarchar = dbmserror);
endif;
If the 4GL calls a 3GL procedure that produces an error in an exec 4GL statement (such as using an invalid attribute name or trying to fetch a character-valued global variable into an integer-valued host variable), error handling must be done in the 3GL procedure. 4GL has no constructs to examine whether errors occurred.
Last modified date: 12/20/2023