[unixODBC-support] A problem with MSSQL and WCHAR

Peter Moss kiwilager at gmail.com
Wed Jan 18 16:16:48 GMT 2006


I've installed on my Gentoo (2.6.14-r5) box both FreeTDS (0.63) and unixODBC (2.2.11) and am having a problem with accessing data from a remote site.
My odbc.ini contains the following two entries ...
==========[MSSQL-GVTI-PLAT]Driver          = /usr/lib/libtdsodbc.soSetup           = /usr/lib/libtdsS.soDescription             = PlatypusTrace           = NoServer          = <a valid ip number>Database                = platPort            = 1433TDS_Version             = 8.0FileUsage               = 1
[MSSQL-GVTI-DUDE]Driver          = /usr/lib/libtdsodbc.soSetup           = /usr/lib/libtdsS.soDescription             = DudeTrace           = NoServer          = <a valid ip number>Database                = ForSurePort            = 1433TDS_Version             = 4.2FileUsage               = 1==========
tsql will connect to both databases and retrieve data with no problems using either -H or -S. Concentrating just on the MSSQL-GVTI-PLAT entry, which references a MSSQL 2000 server on Windows 2000, if I enter the following ...
==========tamatea ~ # tsql -S MSSQL-GVTI-PLAT -U ***** -P *****locale is "C"locale charset is "ANSI_X3.4-1968"1> select username from plat.dbo.customer                  2> go==========
the I get the following output (last few lines shown).
==========wirelesscareywirelessburkeywirelesspenawirelessnoland1>                 ==========
If I then try the same thing using isql 
==========tamatea ~ # isql MSSQL-GVTI-PLAT ***** *****+---------------------------------------+| Connected!                            ||                                       || sql-statement                         || help [tablename]                      || quit                                  ||                                       |+---------------------------------------+SQL> select username from customer                       ==========

the last few lines of the output look like
==========| wirelesscarey                                                                                       || wirelessburkey                                                                                      || wirelesspena                                                                                        || wirelessnoland                                                                                      |+-----------------------------------------------------------------------------------------------------+SQLRowCount returns 21292129 rows fetchedSQL>                                                                                                                                  ==========
So believing everything was working as it should I then started developing my application using QT (3.3.4) under KDE (3.4.3) and started having problem retrieving data using both QSqlCursor and QSqlQuery. After a lot of time looking at the trace log and trying various combinations the problem came down to fetching CHAR (or VARCHAR) fields, numeric fields are fine but the trace log shows something like the following for every type of CHAR field
==========[ODBC][26349][SQLGetData.c][224]                Entry:                        Statement = 0x81dc250                        Column Number = 6                        Target Type = -8 SQL_WCHAR                        Buffer Length = 255                        Target Value = 0x8246068                        StrLen Or Ind = 0xbf9fd3cc[ODBC][26349][SQLGetData.c][470]                Exit:[SQL_ERROR]                        Buffer = Indicator = -2                        Strlen Or Ind = 0xbf9fd3cc -> -2==========
At this point I found iusql and ran the same test as described above for isql and the result was
==========SQL> select username from customer+-----------------------------------------------------------------------------------------------------+| uenm                                                                                                |+-----------------------------------------------------------------------------------------------------++-----------------------------------------------------------------------------------------------------+SQLRowCount returns -1SQL>                                                                                                                     ==========
Is this a known issue? Is there an available solution/patch?Have I completely missed something?
Thanks in advancePeter Moss



More information about the unixODBC-support mailing list