Installation guide

6. mxODBC Connection Objects
The DB-API 2.0 mandates that database warnings must raised as
mx.ODBC.Warning exception, but mostly because at the time of writing, the
Python warning module did not yet exist.
For some applications it may be more useful to report warnings via Python
warnings. The application could then use the standard Python warning filters
to report or filter the warnings in an appropriate way.
Another alternative is to simply ignore such warnings. Some ODBC are rather
verbose when it comes to warnings.
Note that a possibly registered
.errorhandler will still be called in all these
cases, however, the mxODBC default error handler will use the
.warningformat to determine how to react to database warnings.
Possible values are (see the Constants
section 10.5 for details):
ERROR_WARNINGFORMAT (default)
Report warnings in the usual DB-API 2.0 way and raise a Warning
exception.
WARN_WARNINGFORMAT
Instead of raising a Warning exception, issue a
mx.ODBC.DatabaseWarning which is a Python Warning subclass and
can be filtered using the standard Python warnings module
mechanisms.
IGNORE_WARNINGFORMAT
Silently ignore the database warning.
The warning will still be added to the
.message attribute, but no further
action is taken.
This value is inherited by all cursors created from the connection at creation
time. Note that changing the value of this attribute will not change the warning
format for existing cursors using this connection.
6.8.1 Additional Attributes
In addition to the above attributes, all exception objects used by the connection's
subpackage are also exposed on the connection objects as attributes, e.g.
connection.Error gives the Error exception of the subpackage which was used
to create the connection object.
See the Exceptions and Error Handling
section 10 for details and names of these
error attributes.
101