[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
Fri Mar 6 13:31:12 GMT 2015


On 05/03/15 22:55, Daniel Kasak wrote:
> I've installed DBD::ODBC from git just now and tested. Same error :/

ok, that rules that out.

Can you give us a small example bit of perl which demonstrates the problem.

The schema for the table would be useful too.

Martin

> On Fri, Mar 6, 2015 at 8:06 AM, Daniel Kasak <d.j.kasak.dk at gmail.com <mailto:d.j.kasak.dk at gmail.com>> wrote:
>
>     Hi. Thanks for the responses :)
>
>     I'm using DBD::ODBC version 1.50, which is the latest version I see on CPAN ( and my cpan client agrees ).
>
>     I'm not using bound input parameters on this particular connection - I'm using it on other connections inside the app, but definitely not this connection. The window where this particular failure happens is a SQL client. Users can enter any SQL they want. I do very limited parsing to detect whether they've entered a 'select' query or not. If it's a select, the SQL gets passed to Gtk3::Ex::DBI ( which is also my code ) as a 'pass-through' query ... in which case no further parsing is done, and bound input parameters are not used. The SQL gets executed, and a datasheet is populated from the results of the query execution.
>
>     I've just rebooted into Windows ... and yes I have DBD::ODBC version 1.50 in Windows too.
>
>     Dan
>
>     On Fri, Mar 6, 2015 at 2:02 AM, Martin J. Evans <bohica at ntlworld.com <mailto:bohica at ntlworld.com>> wrote:
>
>         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 <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 <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 <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
>
>
>         _________________________________________________
>         unixODBC-support mailing list
>         unixODBC-support at mailman.__unixodbc.org <mailto:unixODBC-support at mailman.unixodbc.org>
>         http://mailman.unixodbc.org/__mailman/listinfo/unixodbc-__support <http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support>
>
>
>



More information about the unixODBC-support mailing list