X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/a203f6c0995030dc59ad4c0bbd3104d67ac4ac66..d6d8b172806a21e5c5c341f75b0f1213d5d52e94:/docs/latex/wx/tdb.tex?ds=sidebyside diff --git a/docs/latex/wx/tdb.tex b/docs/latex/wx/tdb.tex index e638b4ea19..71a470d202 100644 --- 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 @@ -270,7 +272,7 @@ only forward scrolling cursors, or forward and backward scrolling cursors (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 @@ -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 @@ -622,7 +624,7 @@ if SQL logging is turned on for the classes. 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 @@ -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); // -----------------------------------------------------------------------