[unixODBC-support] [SOLVED] unixODBC skipping every other char in status messages.

ML d4t4full at gmail.com
Fri Nov 20 11:41:22 GMT 2015

On 2015-11-19 12:19, Nick Gorham wrote:
> On 19/11/15 15:15, ML wrote:
>> Hi, there, first post but long time (final) user of unixODBC. My excuses
>> for the length.
>> My setup is two Desktop Ubuntu 14.04.3 LTS (a 64-bit host and a 32-bit
>> virtual machine), and I'm using unixODBC with FreeTDS on both to connect
>> to MSSQL Servers.
>> The problem I have is in a C command-line program I created (two
>> versions compiled, 32-bit and 64-bit) which tries to connect to a server
>> and run a user-typed query.
>> The program works as long as the connection string I feed to
>> SQLDriverConnect() is right, but it fails with very weird messages if
>> -for example- the Database, Username or Password are not right.
>> It does not matter the MSSQL version I connect because the connection
>> attempt fails (on purpose, when I feed bad data).
>> I do this in order to see if I can infer better messages to the final
>> user of my program, but it is the programmer in this case that's
>> baffled...
>> I am not using DSNs at all. In fact, this all started because I want to
>> add connection string support to the Gambas3 gb.db.odbc component (which
>> I did).
>> Just in case, this is an example connection string I would feed the
>> program via command-line:
>> "DRIVER=FreeTDS;TDS_VERSION=7.2;SERVER=<serverNameOrIP>;PORT=<tcpPort>;UID=<username>;PWD=<passowrd>;DATABASE=<database>"
>> The problem is that it looks like the response text skips every other
>> character, making the message completely unreadable.
>> Please note that only unixODBC messages are affected, while driver
>> messages (FreeTDS in these two cases) are OK.
>> Tried changing TDS_VERSION to 0, 4.2, 7, 7.3, etc, with the same
>> outcome, but those are driver directives.
>> The problem affects both 32 and 64 bits versions of the program.
>> A sample unixODBC error from the 32-bit version where I supplied a bad
>> password on purpose (first line is text printed from the program
>> itself):
>>    The driver reported the following diagnostics whilst running
>> SQLDriverConnect or SQLConnect (-1)
>>    400::1:18456:[nxDC[reD]SLSre]oi aldfrue Pacr'
>>    001::2:0:[nxDC[reD]SLSre]nbet onc odt ore;Ph�
> Your app probably thinks its calling a unicode function and getting a
> unicode string, unixODBC (ODBC in general) uses 16 bit unicode, your
> app is probably using 32 bit unicode.

Well, half and half. I'm posting this hoping someone in my same situation
can benefit from it.

My solution was plain replace SQLGetDiagRec() with SQLGetDiagRecW().

I called SQLGetDiagRec() from internet examples and even believed there was
an issue in unixODBC because whole programming environments like Python
were having the exact same issue. The examples I used did not come from any
amateurs, a couple came from IBM/DB2 and some other(s) from Microsoft.

Well, turns out I was calling the wrong function. For unknown (to me)
SQLGetDiagRec() does return weird things, but SQLGetDiagRecW() does not.
Actually, it looks like something (compiler, directives, whatever) mapped my
SQLGetDiagRec() calls to SQLGetDiagRecA(), which outputs the same

For the record, the actual error (username removed, string length kept) was:
  The driver reported the following diagnostics whilst running
SQLDriverConnect or SQLConnect (-1)
  42000:1:18456:[unixODBC][FreeTDS][SQL Server]Login failed for user
  08001:2:0:[unixODBC][FreeTDS][SQL Server]Unable to connect to data source

Wow... The original garbage went past the last characters in the "good"
That could lead to segfaults. Fortunately for me, it did not.

Thanks a lot for the pointers (pun intended) and regards,

More information about the unixODBC-support mailing list