added wxConvUI which determines the conversion used for the UI elements and can be...

[wxWidgets.git] / docs / latex / wx / tdb.tex

diff --git a/docs/latex/wx/tdb.tex b/docs/latex/wx/tdb.tex
index e674560b8a7de956ab638b5564ce90a9174c4569..71a470d202c3793f526839cf81f0b1adfaae969c 100644 (file)
--- a/docs/latex/wx/tdb.tex
+++ b/docs/latex/wx/tdb.tex
@@ -25,18 +25,20 @@ software with these classes, but at the time of the writing of this document,
 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 
@@ -557,9 +559,9 @@ can specify anywhere from one column up to all columns in the table.
 
 \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 
@@ -833,9 +835,9 @@ they also needed to take in to account different database manufacturers and
 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 
@@ -912,9 +914,14 @@ functionality as the driver can emulate.
 
 {\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}
 
@@ -1017,9 +1024,9 @@ table = new wxDbTable(db, tableName, numTableColumns, wxT(""),
 // 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);
 
 
 // -----------------------------------------------------------------------