SYNOPSIS

\*(T<#include <opendbx/api.h>\*(T>

\*(T<int odbx_error_type\*(T> \kx \*(T<(odbx_t* handle, int error);\*(T>

DESCRIPTION

\*(T<odbx_error_type\*(T>() gives an indication about the severity of the error code returned by the last function call and supplied via the \*(T<error\*(T> parameter. It can be used to distinguish critical errors from warnings and enables an application to react appropriately. While applications usually can continue if warnings occur by informing the user and taking measures on the application logic level, severe errors always require to recreate the connection. On both cases, all errors returned are overwritten when the next odbx_*() function is called. This function is available since release 1.1.2.

Let's take \*(T<odbx_query\*(T>() (or any other function) as example, which returned an error. If the return value of odbx_error_type() is negative, you've hit a severe error like the connection to the server is broken. In this case you have to call \*(T<odbx_unbind\*(T>(), \*(T<odbx_finish\*(T>(), \*(T<odbx_init\*(T>() and \*(T<odbx_bind\*(T>() in this order to recreate the connection. Otherwise, if the return value was positive your statement might have been not understood by the database server. Here you can continue to send the next statement to the server without the need to recreate the connection.

The \*(T<handle\*(T> parameter is the connection object created and returned by \*(T<odbx_init\*(T>() if the call was successful and it becomes invalid as soon as it was supplied to \*(T<odbx_finish\*(T>(). Anyhow, it isn't necessary to supply a valid handle for errors which use error codes not equal to -\*(T<ODBX_ERR_BACKEND\*(T>. Therefore, it's possible to use \*(T<odbx_error_type\*(T>() even if \*(T<odbx_init\*(T>() returned an error. If -\*(T<ODBX_ERR_BACKEND\*(T> is supplied in this case nevertheless, the return value will indicate a critical error.

All values returned by odbx_*() functions can be feed directly via the \*(T<error\*(T> parameter into this function. If the given value doesn't indicate an error, the returned code will always be zero for successful completion. Negative values will be separated into classes for critical errors and warnings instead.

RETURN VALUE

On success, i.e. if \*(T<ODBX_ERR_SUCCESS\*(T> or a positive value is supplied as value of \*(T<error\*(T>, the function returns zero. Otherwise, there will be positive and negative values returned, depending on the severity of the error occurred.

Positive values (values greater than zero) indicate recoverable errors which leave the database connection intact. An example might be a warning if a record couldn't be inserted into the table for any reason. In this case, further statements can be send to the database server and they are likely to succeed.

On the other hand, if negative values (values less than zero) are returned, there has happened a severe error in the backend module, the native database client library or the database server. The connection to the server might be lost or an out of memory condition might has been occurred. This means that all further calls to the OpenDBX library will probably fail and the only way to recover from this situation is to clean up the connection by using \*(T<odbx_unbind\*(T>() and \*(T<odbx_finish\*(T>() and trying to create a new connection from ground up.

ERRORS

This function doesn't return any errors.

RELATED TO odbx_error_type…

\*(T<odbx_finish\*(T>(), \*(T<odbx_init\*(T>(), \*(T<odbx_unbind\*(T>()