unixODBC skipping every other char in status messages.

classic Classic list List threaded Threaded
4 messages Options
ML
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

unixODBC skipping every other char in status messages.

ML
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�

Here's also a sample from the 64-bit version, trying the same bad
password above:

  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�[

And another sample, this time trying with MDBTools against an MDB file
with the 64-bit version:

  The driver reported the following diagnostics whilst running
SQLDriverConnect or SQLConnect (-1)
  001:1:1:[nxDCCudntfn S o B ncnetsrn

My guess is that the text [nxDC is actually [unixODBC], but with every
other character skipped.
Likewise, [reD] would be [FreeTDS], SLSre] would be [SQLServer].
Also, in the MDB case, [nxDCCudntfn may be [unixODBC]Could not find. I
cannot make heads or tails of the rest of the text.

Is anybody else having this issue? What would the solution be?

TIA,
zxMarce.
_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unixODBC skipping every other char in status messages.

Nick Gorham-2
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
_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unixODBC skipping every other char in status messages.

Michael König
In reply to this post by ML
Hi there!

I assume it has something to do with 16bit Unicode vs. 8bit ASCII or 32 bit Unicode. Some suggestions:
* Check if you use unixODBC's unicode functions with proper data types.
* Check if the driver you use has been compiled for a different ODBC driver manager such as iODBC. Some drivers also have some configuration option which decides the bitness of Unicode operations.

Good luck!

Michael

Am 19.11.2015 um 16:15 schrieb ML:
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�

Here's also a sample from the 64-bit version, trying the same bad
password above:

  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�[

And another sample, this time trying with MDBTools against an MDB file
with the 64-bit version:

  The driver reported the following diagnostics whilst running
SQLDriverConnect or SQLConnect (-1)
  001:1:1:[nxDCCudntfn S o B ncnetsrn

My guess is that the text [nxDC is actually [unixODBC], but with every
other character skipped.
Likewise, [reD] would be [FreeTDS], SLSre] would be [SQLServer].
Also, in the MDB case, [nxDCCudntfn may be [unixODBC]Could not find. I
cannot make heads or tails of the rest of the text.

Is anybody else having this issue? What would the solution be?

TIA,
zxMarce.
_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support


--
Dr. Michael König
Software Engineer

Blue Yonder GmbH
Ohiostraße 8
76149 Karlsruhe

Tel +49 (0) 721 383 117 38
Fax +49 (0) 721 383 117 69

[hidden email]
www.blue-yonder.com
Registergericht Mannheim, HRB 704547
USt-IdNr. DE 277 091 535
Geschäftsführer: Jochen Bossert, Uwe Weiss (CEO)


_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
ML
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [SOLVED] unixODBC skipping every other char in status messages.

ML
In reply to this post by Nick Gorham-2
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)
reasons,
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
garbage.

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"
error.
That could lead to segfaults. Fortunately for me, it did not.

Thanks a lot for the pointers (pun intended) and regards,
zxMarce.
_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Loading...