[unixODBC-support] unicode issues :/ st_fetch/SQLFetch (long truncated DBI attribute LongTruncOk not set and/or LongReadLen too small)
d.j.kasak.dk at gmail.com
Thu Mar 5 13:47:26 GMT 2015
I'm struggling to understand some issues I'm seeing talking to SQL Server.
I'm pretty sure I've isolated the issue to unixODBC.
I've loaded by Microsoft's AdventureWorksDW2014 database for testing
purposes. To give an idea of the data, here's a query I've been testing. It
fails in Linux, but runs and displays find in Windows:
As you can see, I'm substring-ing out each character ( I'm debugging yet
other issues ), and also getting hex values for each character. Note the
6th character ( column S6 ), with hex value f3 ( column H6 ). Also note the
complete string at the end.
Note in this screenshot, the last column - the complete string. That
doesn't look right. It's difficult to say *why* it doesn't look right, but
my feeling is that the driver is sending a multibyte character, and
somewhere along the line it's being interpreted as 2 single-byte characters.
You might have noticed I'd commented out the expression for S6 in the Linux
query. If I run the query with the S6 expression, I get an empty recordset
back, and the following in STDERR:
DBD::ODBC::st fetchrow_array failed: st_fetch/SQLFetch (long truncated DBI
attribute LongTruncOk not set and/or LongReadLen too small) (SQL-HY000)
Now ... note that this is a single character ... and that things weren't
too long when I selected the entire column at once. I've tried setting
LongReadLen to various large values. That doesn't stop this error. If I
also set LongTruncOk, the error disappears, *and* I get a recordset, but
the S6 column is null.
What's going on here? If this was related to the 1st issue ( and I feel it
might be ) ... I'd say the driver manager was expecting a single byte
character only for the entire field, but was receiving a multi-byte
I built unixODBC-2.3.2 with the following configure options:
--enable-iconv --disable-drivers --disable-driverc
I've tested with freetds-0.91, *and* with Microsoft's native client for
Linux. Interestingly, I get exactly the same behaviour with both.
I've obviously also tested in Windows, which produced the 1st screenshot.
Based on the fact that it works perfectly in Windows, I'd assume
Microsoft's drivers, *and* DBD::ODBC, *and* my code are behaving well. And
based on the fact that both freetds and MS's drivers produce exactly the
same failure under Linux, I'm guessing the problem lies somewhere in
unixODBC. I do concede that it's possible that the same bug exists in
freetds and Microsoft's native client, and that unixODBC is completely
An odbc trace is at ( pasting it in the message make the message too big to
post, apparently ):
Note that this will have *two* executions of the query. My app 1st executes
each query with the filter "where 0=1" ... to analyse the columns and
decide how to go about things. Then it execute the 'real' query.
Any help greatly appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the unixODBC-support