Using CA InterTest for CICS with DB2 and SQL/DS Programs › SQL Return Codes › How to Handle SQL Error Codes

How to Handle SQL Error Codes

Two techniques are commonly used by programmers to handle SQL error return codes after each SQL request:

• Check the SQLCODE data field immediately after each SQL request
• Branch to a common error handling routine

Checking the SQLCODE immediately tells you which request produced the error so you can create an error message reflecting that request. However, this method might not be efficient if you have many similar routines throughout your program—one for each SQL request. Moreover, if you discover a logic error in such an error handling routine, you must correct the error in all the routines throughout the program.

Branching to a common error handling routine results in a smaller program and simplifies the task of debugging the routine. However, you might not be able to determine which SQL request caused the error unless you pass an indicator to the error routine, which is then reflected in the generated error message.

Users who want to check the SQLCODE field in the SQLCA after each SQL request should set unconditional breakpoints at each occurrence of SQLCODE. The chapter "Using Breakpoints" explains how to set breakpoints at each occurrence of a data field. Your program must be compiled or assembled symbolically with the option to produce a Cross‑Reference listing.

Users who branch to a common error handling routine should set request breakpoints at all DB2 or SQL/DS calls and then single‑step through the breakpoint, as described in the section Halt Programs Before and After Each SQL Request. This technique does not require that programs be compiled or assembled symbolically.

In either case, keep SQLCODE in the Keep window so its value can be checked easily. The Keep window is described in the chapter "Breakpoint Activities."