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

Nick Gorham nick at lurcher.org
Thu Mar 5 14:08:52 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

Hi,

  Well it may be unixODBC, but looking at that log, the app is using 
bound columns, and the driver manager is not involved with returning 
data in that case.

Not wanting to point fingers, but I would suspect that its a DBD::ODBC 
issue, are they the same version in both cases? are they both built the 
same?

-- 
Nick


More information about the unixODBC-support mailing list