DB_CALLBACK_DEBUG_MESSAGE   The supplied function is called once for each debug message and is passed a null-terminated string containing the text of the debug message. A debug message is a message that is logged to the LogFile file. In order for a debug message to be passed to this callback, the LogFile connection parameter must be used. The string normally has a newline character (\n) immediately before the terminating null character. The prototype of the callback function is as follows:

void SQL_CALLBACK debug_message_callback(
SQLCA * sqlca,
char * message_string );

For more information, see LogFile connection parameter [LOG].

DB_CALLBACK_START   The prototype is as follows:

void SQL_CALLBACK start_callback( SQLCA * sqlca );

This function is called just before a database request is sent to the server. DB_CALLBACK_START is used only on Windows.

DB_CALLBACK_FINISH   The prototype is as follows:

void SQL_CALLBACK finish_callback( SQLCA * sqlca );

This function is called after the response to a database request has been received by the interface DLL. DB_CALLBACK_FINISH is used only on Windows operating systems.

DB_CALLBACK_CONN_DROPPED   The prototype is as follows:

void SQL_CALLBACK conn_dropped_callback (
SQLCA * sqlca,
char * conn_name );

This function is called when the database server is about to drop a connection because of a liveness timeout, through a DROP CONNECTION statement, or because the database server is being shut down. The connection name conn_name is passed in to allow you to distinguish between connections. If the connection was not named, it has a value of NULL.

DB_CALLBACK_WAIT   The prototype is as follows:

void SQL_CALLBACK wait_callback( SQLCA * sqlca );

This function is called repeatedly by the interface library while the database server or client library is busy processing your database request.

You would register this callback as follows:

db_register_a_callback( &sqlca,
   DB_CALLBACK_WAIT,
   (SQL_CALLBACK_PARM)&db_wait_request );

DB_CALLBACK_MESSAGE   This is used to enable the application to handle messages received from the server during the processing of a request.

The callback prototype is as follows:

void SQL_CALLBACK message_callback(
SQLCA * sqlca,
unsigned char msg_type,
an_sql_code code,
unsigned short length,
char *  msg
);

The msg_type parameter states how important the message is and you may want to handle different message types in different ways. The available message types are MESSAGE_TYPE_INFO, MESSAGE_TYPE_WARNING, MESSAGE_TYPE_ACTION, and MESSAGE_TYPE_STATUS. These constants are defined in sqldef.h. The code field may provide a SQLCODE associated with the message, otherwise the value is 0. The length field tells you how long the message is. The message is not null-terminated.

For example, the Interactive SQL callback displays STATUS and INFO message on the Messages tab, while messages of type ACTION and WARNING go to a window. If an application does not register this callback, there is a default callback, which causes all messages to be written to the server logfile (if debugging is on and a logfile is specified). In addition, messages of type MESSAGE_TYPE_WARNING and MESSAGE_TYPE_ACTION are more prominently displayed, in an operating system-dependent manner.

DB_CALLBACK_VALIDATE_FILE_TRANSFER   This is used to register a file transfer validation callback function. Before allowing any transfer to take place, the client library will invoke the validation callback, if it exists. If the client data transfer is being requested during the execution of indirect statements such as from within a stored procedure, the client library will not allow a transfer unless the client application has registered a validation callback. The conditions under which a validation call is made are described more fully below.

The callback prototype is as follows:

int SQL_CALLBACK file_transfer_callback(
SQLCA * sqlca,
char * file_name,
int is_write
);

The file_name parameter is the name of the file to be read or written. The is_write parameter is 0 if a read is requested (transfer from the client to the server), and non-zero for a write. The callback function should return 0 if the file transfer is not allowed, non-zero otherwise.

For data security, the server tracks the origin of statements requesting a file transfer. The server determines if the statement was received directly from the client application. When initiating the transfer of data from the client, the server sends the information about the origin of the statement to the client software. On its part, the embedded SQL client library allows unconditional transfer of data only if the data transfer is being requested due to the execution of a statement sent directly by the client application. Otherwise, the application must have registered the validation callback described above, in the absence of which the transfer is denied and the statement fails with an error. Note that if the client statement invokes a stored procedure already existing in the database, then the execution of the stored procedure itself is considered not to have been for a client initiated statement. However, if the client application explicitly creates a temporary stored procedure then the execution of the stored procedure results in the server treating the procedure as having been client initiated. Similarly, if the client application executes a batch statement, then the execution of the batch statement is considered as being done directly by the client application.