[unixODBC-support] unicode issues :/ st_fetch/SQLFetch (long truncated DBI attribute LongTruncOk not set and/or LongReadLen too small)

Martin J. Evans bohica at ntlworld.com
Thu Mar 5 15:02:51 GMT 2015


On 05/03/15 13:47, Daniel Kasak wrote:
> Hi all.
>
> 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:
>
> http://tesla.duckdns.org/images/windows_odbc.png
>
> 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.
>
> ---
>
> Issue 1)
>
> http://tesla.duckdns.org/images/linux_odbc_1.png
>
> 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.
>
> Issue 2)
>
> 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 character.
>
> ---
>
> I built unixODBC-2.3.2 with the following configure options:
>   --enable-iconv --disable-drivers --disable-driverc --with-iconv-char-enc=UTF8 --with-iconv-ucode-enc=UTF16LE
>
> 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 innocent.
>
> An odbc trace is at ( pasting it in the message make the message too big to post, apparently ):
> http://tesla.duckdns.org/downloads/trace.log
>
> 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.
>
> Dan

Sounds like it could be this bug:

1.51_3 2015-01-17

   [BUG FIXES]

   RT101579 - using bound input parameters for numeric columns (e.g.,
   SQL_NUMERIC) only works the first time and will quite likey fail
   with "string data, right truncation" on the second and subsequent
   calls to execute. Thanks to Laura Cox for finding.

What version of DBD::ODBC are you using?

What does you perl code look like?

Martin



More information about the unixODBC-support mailing list