ODBC
As alternative to wxODBC you can also use wx bindings to Debea library (http://debea.net/trac/wiki/WxDba).
The wxWidgets manual has an extensive overview section regarding the wxDb and wxDbTable classes, in addition to the standard wxWidgets class documentation.
The ODBC classes (commonly referred to as wxODBC) are tested and confirmed to work with the following databases as of version 2.5.4 of wxWidgets:
DB2 DBASE (III, IV) Firebird Informix Interbase MaxDB (from MySQL) MS Access MS SQLServer MySQL Oracle (7, 8, 9 are tested) PervasiveSQL, PostgreSQL Sybase Adaptive Server Anywhere Sybase Adaptive Server Enterprise Virtuoso XBASE Sequiter
Support for adding support for additional databases post-release is being added for v2.6, so that as additional databases qualify as being supported, they can be added as a one of the "dbmsFuture1" ... "dbmsFuture10" enums, without breaking binary compatibility.
CONFIGURING wxWidgets FOR ODBC SUPPORT
Before compiling wxWidgets, you must enable ODBC support, as by default ODBC support is not included. Edit your setup.h for wxWidgets, and set:
#define wxUSE_ODBC 1
There are several associated wxUSE_XXXXXX settings in setup.h following the wxUSE_ODBC setting.
#define wxODBC_FWD_ONLY_CURSORS 1
This setting should only be disabled if you are certain that all the databases you will target for use (as well as the drivers that will access the databases) support backward scrolling cursors. All databases/drivers support forward scrolling cursors, hence it is set as the default.
#define wxODBC_BACKWARD_COMPATABILITY 0
This setting allows older programs to access older API formats of the wxODBC classes. As of v2.6 of wxWidgets, this setting will be ignored in almost all cases, forcing users to update to the APIs that have been in use since v2.2 of wxWidgets.
CONFIGURING ODBC
Under MS Windows, ODBC is configured using the ODBC Administrator in the "Administrative Tools" section of Control Panel.
Under Unix, either iODBC (http://www.iodbc.org) or unixODBC (http://www.unixodbc.org) are used to provide ODBC support.
If using iODBC, it is strongly recommended to use v3.52 or higher from the iODBC website, rather than the v2.x currently shipping with wxWidgets. Also, you should use the v3.52.1 iODBC driver, or higher. In various earlier releases of the v3.5x drivers, features used by wxODBC were broken, fixed, and broken again. v3.51.02 of the driver has been tested and works with wxODBC, but v3.51.03 fails. v3.52.1 of the iODBC driver has been reported as working correctly.
If using unixODBC, please note that Unicode with GTK builds may require -DSQL_WCHART_CONVERT to be added to your CXXFLAGS. For more details, see the notes below.
SAMPLES/EXAMPLES/DEMOS
The overview in the wxWidgets manual has a very simple example of using the wxODBC classes that is heavily documented, and has no UI code involved. For a beginner
Before writing/testing your own first application using wxODBC, it is strongly recommended that you try compiling /wxWidgets/samples/db test your wxWidgets library with your target database(s). This is a fairly feature-rich UI based program that utilizes the wxODBC classes, giving examples of how to use most of the common features of wxODBC. It is tested to work with all of the above databases. Standard features, as well as a few more advanced features such as BLOBS, wxDbGrid, and other features are included as part of the sample.
A contributed demo program using more advanced features of wxODBC can be found in /wxWidgets/demos/dbbrowse.
Some infos about accessing MySQL databases through the ODBC classes:
I tried to run the database sample program under samples/db with an MySQL database and the newest MySQL ODBC driver 3.51.10. (under wxWidgets 2.5.3). It is not working because of a bug in the MySQL ODBC driver. The MyODBC gives back an error when the wxDB tries to check what data types are supported by the database. The error is when checking for SQL_TIMESTAMP, SQL_DATE and SQL_DATETIME. This bug was resolved in MyODBC 3.51.02, but seems to reoccur in a later version (3.51.03). It's no solution to install the old MyODBC driver (since there are other bugs maybe).
One work around could be to turn off the checking of the supported data types. Go into src/common/db.h and search for failOnDataTypeUnsupported=true (it occurs three times) and change it to failOnDataTypeUnsupported=false and recompile. In fact, checking the data types still will be done, but the wxDB::Open() will not return false if data type checking fails.
GTK/Unicode/wxODBC is being reported as failing to build when using unixODBC with wxWidgets v2.5.4. The reason for this is that in this combination, wchar_t is not defined the same as under iODBC or MS Windows. A possible solution was found by Michalis Kabrianis and posted to SourceForge at:
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1163141&group_id=9863
Basically the solution is to define -DSQL_WCHART_CONVERT in the CXXFLAGS of the build system. This causes wchar_t to be defined in unixODBC buids the same way it is defined in iODBC.
The potential problem with this is that the definition of TCHAR is also affected by this flag, changing the definition to use what is currently defined on Windows systems. This may or may not be a problem, but it is documented here to make people aware.