users have successfully used the classes with the following datasources:
\begin{itemize}\itemsep=0pt
-\item Oracle (v7, v8, v8i)
-\item Sybase (ASA and ASE)
-\item MS SQL Server (v7 - minimal testing)
-\item MS Access (97 and 2000)
-\item MySQL
+\item DB2
\item DBase (IV, V)**
-\item PostgreSQL
+\item Firebird
\item INFORMIX
-\item VIRTUOSO
-\item DB2
\item Interbase
+\item MS SQL Server (v7 - minimal testing)
+\item MS Access (97, 2000, 2002, and 2003)
+\item MySQL (2.x and 3.5 - use the 2.5x drivers though)
+\item Oracle (v7, v8, v8i)
\item Pervasive SQL
+\item PostgreSQL
+\item Sybase (ASA and ASE)
+\item XBase Sequiter
+\item VIRTUOSO
\end{itemize}
An up-to-date list can be obtained by looking in the comments of the function
(see the section in "WHERE TO START" on cursors for more information on
cursors). This default can be overridden by passing a second parameter to
either the \helpref{wxDbGetConnection}{wxdbfunctions} or
-\helpref{wxDb constructor}{wxdbconstr}. The default is 1.}
+\helpref{wxDb constructor}{wxdbctor}. The default is 1.}
\twocolitem{wxODBC\_BACKWARD\_COMPATABILITY}{Between v2.0 and 2.2, massive
renaming efforts were done to the ODBC classes to get naming conventions
similar to those used throughout wxWidgets, as well as to preface all wxODBC
\begin{verbatim}
table->SetColDefs(0, "FIRST_NAME", DB_DATA_TYPE_VARCHAR, FirstName,
- SQL_C_CHAR, sizeof(FirstName), true, true);
+ SQL_C_WXCHAR, sizeof(FirstName), true, true);
table->SetColDefs(1, "LAST_NAME", DB_DATA_TYPE_VARCHAR, LastName,
- SQL_C_CHAR, sizeof(LastName), true, true);
+ SQL_C_WXCHAR, sizeof(LastName), true, true);
\end{verbatim}
Notice that column definitions start at index 0 and go up to one less than
To use the table and the definitions that are now set up, we must first
define what data we want the datasource to collect in to a result set, tell
-it where to get the data from, and in what sequence we want the data returned.
+it where to get the data from, and in which sequence we want the data returned.
\begin{verbatim}
// the WHERE clause limits/specifies which rows in the table
different ODBC driver manufacturers. Because of all the possible combinations
of OS/database/drivers, it is impossible to say that these classes will work
perfectly with datasource ABC, ODBC driver XYZ, on platform LMN. You may run
-in to some incompatibilities or unsupported features when moving your
+into some incompatibilities or unsupported features when moving your
application from one environment to another. But that is what makes
-cross-platform programming fun. It is also pinpoints one of the great
+cross-platform programming fun. It also pinpoints one of the great
things about open source software. It can evolve!
The most common difference between different database/ODBC driver
{\bf UNICODE with wxODBC classes}
-The ODBC classes support for Unicode is yet in early experimental stage and
-hasn't been tested extensively. It might work for you or it might not: please
-report the bugs/problems you have encountered in the latter case.
+As of v2.6 of wxWidgets, the wxODBC classes now fully support the compilation
+and use of the classes in a Unicode build of wxWidgets, assuming the compiler
+and OS on which the program will be compiled/run is Unicode capable.
+
+The one major difference in writing code that can be compiled in either
+unicode or non-unicode builds that is specific to the wxODBC classes is to
+use the SQL\_C\_WXCHAR datatype for string columns rather than SQL\_C\_CHAR or
+SQL\_C\_WCHAR.
\subsection{wxODBC - Sample Code}\label{wxodbcsamplecode1}
// returned back to the client.
//
table->SetColDefs(0, wxT("FIRST_NAME"), DB_DATA_TYPE_VARCHAR, FirstName,
- SQL_C_CHAR, sizeof(FirstName), true, true);
+ SQL_C_WXCHAR, sizeof(FirstName), true, true);
table->SetColDefs(1, wxT("LAST_NAME"), DB_DATA_TYPE_VARCHAR, LastName,
- SQL_C_CHAR, sizeof(LastName), true, true);
+ SQL_C_WXCHAR, sizeof(LastName), true, true);
// -----------------------------------------------------------------------