Error handling for cursor declare and open commands

In general, the client application handles errors the same as any other CT-Library application. However, handling errors from a cursor declare or cursor open requires special consideration, as described next.


Cursor declare

If a cursor declare fails (for example, because a table does not exist or the user does not have sufficient privilege to access a table), the application should issue a ct_cancel and drop the command. This cleans up the necessary structures in Open Client and Open Server and synchronizes the client with both the DB2 access service and DB2.


Cursor open

If a cursor open fails (for example, because the number of parameters described in the open does not match the number of parameter markers in the declare), the client application should close and free the cursor and then drop the command. The client application should not issue a ct_cancel in this case.

WARNING! If a cursor declare contains parameter markers but the cursor open does not describe any parameters, DirectConnect for z/OS Option goes into an error state. As a result, the client's connection to the database is dropped when the next command is executed. To recover, the client application must close the connection to the DB2 access service and open a new one.

For more information about error handling, see the Sybase Open Client Client-Library/C Reference Manual.