Programming Guide > Programming Guide > Working with a Database > Handling Database Errors > Choosing an Error Handling Strategy
Was this helpful?
Choosing an Error Handling Strategy
This section discusses some common strategies for detecting and handling DBMS errors. These include:
• Using the DBMSErrorPrinting attribute
• Calling a general error-handling procedure
• Detecting errors when manipulating BitmapObject and StringObject objects
For a discussion of strategies for detecting and handling DBMS errors in DataStream objects, see How You Can Handle DataStream Errors.
How You Can Use the DBMSErrorPrinting Attribute
Another method of handling errors is to call a general error-handling procedure each time an error is detected. For example, the script for the check_out frame in the Videos application calls an error handling procedure after each database statement to detect and handle any DBMS errors. The following code fragment from the check_out frame script calls the error handler:
/* Update video information */
update v_video
set last_checkout =
    :checkout_form.checkout[i].date_out,
    no_checkouts = no_checkouts + 1
where vid_no = :checkout_form.checkout[i].vid_no;

if error_handler(frm = CurFrame, commit_evt =
    'Commit')
    != ER_OK then
        resume;
endif;
...
The if statement in the example calls the error-handling procedure. This procedure first checks to see if there was a DBMS error. If none occurred, it returns ER_OK to the calling program. If an error occurred and the error was not a deadlock error, then the routine displays an error message that includes the generic and local DBMS error number. If the error was a deadlock, the procedure sends an event back to the application to retry the DBMS statement.
The following code is the error handling procedure:
/*
** Name: error_handler -- Detects and handles DBMS
** errors.
**
** Description:
** This procedure first checks if an error occurred
** in the previous DBMS statement. If so, it pops up
** an error message. If the error was deadlock or
** another error for which retry is appropriate, it
** sends an event back to the calling
** frame to retry the DBMS statement.
** No need to roll back the transaction in either
** case because the main_control frame set the
** application's database session to roll back
** automatically for all DBMS errors.
**
** Called By:
** check_out frame.
**
** Parameters:
** frm          Frame which called this procedure.
** commit_evt   Event sent to calling frame when
**              there is a deadlock to retry DBMS
**              statements.
**
** Returns:
** DBSession.ErrorNumber set by previous DBMS
** statement;
** ER_OK (0) if success
*/
procedure error_handler
(
    frm = FrameExec,            /* Calling frame */
    commit_evt = varchar(32),   /* Commit event for
                                ** retries if
                                ** a deadlock
                                ** occurred. */
) =
declare
    err_no = integer not null   /* Error number */
enddeclare
begin
    err_no = CurProcedure.DBSession.ErrorNumber;
    if err_no = 49000 then
    /* We have encountered a deadlock or log
    **  full. */
        message 'Deadlock error occurred while
        updating the database.';
        frm.SendUserEvent(commit_evt);
    elseif err_no != ER_OK then
        message 'Error occurred while making changes
        in the database.' +
        dbms_error_message();
    endif;

    return err_no;
end;
Note:  The error-handling procedure calls another procedure, dbms_error_message, when a non-deadlock DBMS error occurs. This called procedure returns the generic and local error numbers. For the code for the dbms_error_message procedure, see How You Can Use the ErrorNumber and DBMSError Attributes.
How You Can Detect Errors When Working with Bitmaps, String, Long VChar, and Long Byte Objects
How you handle errors when you manipulate bitmaps, long byte, long varchar, or string objects depends on how you have stored these objects and what operations you are performing.
For example, if your bitmaps, long byte, long varchar, or string objects are stored in a file, whenever you use the WriteToFile method you can check the method's return value to detect errors. The WriteToFile method returns 0 if it was successful or a 1 if not.
If your bitmaps and string objects are stored in the database, use the InsertIntoDB, UpdateInDB, and DeleteFromDB methods to manipulate these objects in the database. If your long byte and long varchar objects are stored in the database, use the FetchFromDB or UpdateInDB methods to manipulate these objects in the database. When you do, your error checking should check not only the return status of the method but also the value of DBSessionObject's ErrorNumber attribute because these methods access the database, and it is possible for a DBMS error to occur.
Finally, you can set a FileHandle or DBHandle directly, for example, by an assignment statement. When you do so, you can check the ErrorStatus attribute for errors. For more information about this attribute, see How You Can Use the ErrorStatus Attribute.
 
Last modified date: 06/25/2024