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

Nick Gorham nick at lurcher.org
Thu Nov 19 15:19:01 GMT 2015


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.

-- 
Nick


More information about the unixODBC-support mailing list