<div dir="ltr"><div><div><div><div><div><div>Excellent :) Thanks for helping out.<br><br></div>Code:<br><a href="http://tesla.duckdns.org/downloads/odbc_test.pl">http://tesla.duckdns.org/downloads/odbc_test.pl</a><br><br></div>Table DDL:<br><a href="http://tesla.duckdns.org/downloads/DimCustomer.sql">http://tesla.duckdns.org/downloads/DimCustomer.sql</a><br><br></div>Data:<br><a href="http://tesla.duckdns.org/downloads/DimCustomerData.csv">http://tesla.duckdns.org/downloads/DimCustomerData.csv</a><br><br></div>If it&#39;s easier for you, I can set up port forwarding to my SQL Server instance ( it&#39;s purely for testing this kind of thing ). Let me know ...<br><br></div>The database is Microsoft&#39;s AdventureWorksDW2014 demo database:<br><a href="https://msftdbprodsamples.codeplex.com/releases/view/125550">https://msftdbprodsamples.codeplex.com/releases/view/125550</a><br><br></div><div>It may ( or may not ) be easier for you to just download that demo - it comes as a SQL Server backup file, and you don&#39;t have to mess around with loading the CSV ( I exported it from SQL Server Management Studio ). To be honest, I haven&#39;t used SQL Server for about 15 years, so I&#39;m not sure what he easiest way of loading data is these days.<br><br></div><div>If what I&#39;m seeing is correct though, you can define a table with a single nvarchar column, insert any non-ASCII character, as dummy data to trigger this bug.<br><br></div><div>2 things to note in Linux:<br><br></div><div>1) If you use a substring() function on the column ( selecting *only* to non-ASCII character ), you&#39;ll get zero records back, and the truncation warnings.<br><br>2) If you *don&#39;t* substring() the column, you get data back, but it&#39;s corrupted.<br><br></div><div>In Windows, the above behaves as expected.<br><br></div><div>Let me know if there is anything else you need ...<br><br></div><div>Dan<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 7, 2015 at 12:31 AM, Martin J. Evans <span dir="ltr">&lt;<a href="mailto:bohica@ntlworld.com" target="_blank">bohica@ntlworld.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/03/15 22:55, Daniel Kasak wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;ve installed DBD::ODBC from git just now and tested. Same error :/<br>
</blockquote>
<br></span>
ok, that rules that out.<br>
<br>
Can you give us a small example bit of perl which demonstrates the problem.<br>
<br>
The schema for the table would be useful too.<br>
<br>
Martin<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Fri, Mar 6, 2015 at 8:06 AM, Daniel Kasak &lt;<a href="mailto:d.j.kasak.dk@gmail.com" target="_blank">d.j.kasak.dk@gmail.com</a> &lt;mailto:<a href="mailto:d.j.kasak.dk@gmail.com" target="_blank">d.j.kasak.dk@gmail.com</a><u></u>&gt;&gt; wrote:<br>
<br>
    Hi. Thanks for the responses :)<br>
<br>
    I&#39;m using DBD::ODBC version 1.50, which is the latest version I see on CPAN ( and my cpan client agrees ).<br>
<br>
    I&#39;m not using bound input parameters on this particular connection - I&#39;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&#39;ve entered a &#39;select&#39; query or not. If it&#39;s a select, the SQL gets passed to Gtk3::Ex::DBI ( which is also my code ) as a &#39;pass-through&#39; 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.<br>
<br>
    I&#39;ve just rebooted into Windows ... and yes I have DBD::ODBC version 1.50 in Windows too.<br>
<br>
    Dan<br>
<br></span><span class="">
    On Fri, Mar 6, 2015 at 2:02 AM, Martin J. Evans &lt;<a href="mailto:bohica@ntlworld.com" target="_blank">bohica@ntlworld.com</a> &lt;mailto:<a href="mailto:bohica@ntlworld.com" target="_blank">bohica@ntlworld.com</a>&gt;&gt; wrote:<br>
<br>
        On 05/03/15 13:47, Daniel Kasak wrote:<br>
<br>
            Hi all.<br>
<br>
            I&#39;m struggling to understand some issues I&#39;m seeing talking to SQL Server. I&#39;m pretty sure I&#39;ve isolated the issue to unixODBC.<br>
<br>
            I&#39;ve loaded by Microsoft&#39;s AdventureWorksDW2014 database for testing purposes. To give an idea of the data, here&#39;s a query I&#39;ve been testing. It fails in Linux, but runs and displays find in Windows:<br>
<br></span>
            <a href="http://tesla.duckdns.org/__images/windows_odbc.png" target="_blank">http://tesla.duckdns.org/__<u></u>images/windows_odbc.png</a> &lt;<a href="http://tesla.duckdns.org/images/windows_odbc.png" target="_blank">http://tesla.duckdns.org/<u></u>images/windows_odbc.png</a>&gt;<span class=""><br>
<br>
            As you can see, I&#39;m substring-ing out each character ( I&#39;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.<br>
<br>
            ---<br>
<br>
            Issue 1)<br>
<br></span>
            <a href="http://tesla.duckdns.org/__images/linux_odbc_1.png" target="_blank">http://tesla.duckdns.org/__<u></u>images/linux_odbc_1.png</a> &lt;<a href="http://tesla.duckdns.org/images/linux_odbc_1.png" target="_blank">http://tesla.duckdns.org/<u></u>images/linux_odbc_1.png</a>&gt;<span class=""><br>
<br>
            Note in this screenshot, the last column - the complete string. That doesn&#39;t look right. It&#39;s difficult to say *why* it doesn&#39;t look right, but my feeling is that the driver is sending a multibyte character, and somewhere along the line it&#39;s being interpreted as 2 single-byte characters.<br>
<br>
            Issue 2)<br>
<br>
            You might have noticed I&#39;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:<br>
<br>
            DBD::ODBC::st fetchrow_array failed: st_fetch/SQLFetch (long truncated DBI attribute LongTruncOk not set and/or LongReadLen too small) (SQL-HY000)<br>
<br>
            Now ... note that this is a single character ... and that things weren&#39;t too long when I selected the entire column at once. I&#39;ve tried setting LongReadLen to various large values. That doesn&#39;t stop this error. If I also set LongTruncOk, the error disappears, *and* I get a recordset, but the S6 column is null.<br>
<br>
            What&#39;s going on here? If this was related to the 1st issue ( and I feel it might be ) ... I&#39;d say the driver manager was expecting a single byte character only for the entire field, but was receiving a multi-byte character.<br>
<br>
            ---<br>
<br>
            I built unixODBC-2.3.2 with the following configure options:<br>
               --enable-iconv --disable-drivers --disable-driverc --with-iconv-char-enc=UTF8 --with-iconv-ucode-enc=UTF16LE<br>
<br>
            I&#39;ve tested with freetds-0.91, *and* with Microsoft&#39;s native client for Linux. Interestingly, I get exactly the same behaviour with both.<br>
<br>
            I&#39;ve obviously also tested in Windows, which produced the 1st screenshot. Based on the fact that it works perfectly in Windows, I&#39;d assume Microsoft&#39;s drivers, *and* DBD::ODBC, *and* my code are behaving well. And based on the fact that both freetds and MS&#39;s drivers produce exactly the same failure under Linux, I&#39;m guessing the problem lies somewhere in unixODBC. I do concede that it&#39;s possible that the same bug exists in freetds and Microsoft&#39;s native client, and that unixODBC is completely innocent.<br>
<br>
            An odbc trace is at ( pasting it in the message make the message too big to post, apparently ):<br></span>
            <a href="http://tesla.duckdns.org/__downloads/trace.log" target="_blank">http://tesla.duckdns.org/__<u></u>downloads/trace.log</a> &lt;<a href="http://tesla.duckdns.org/downloads/trace.log" target="_blank">http://tesla.duckdns.org/<u></u>downloads/trace.log</a>&gt;<span class=""><br>
<br>
            Note that this will have *two* executions of the query. My app 1st executes each query with the filter &quot;where 0=1&quot; ... to analyse the columns and decide how to go about things. Then it execute the &#39;real&#39; query.<br>
<br>
            Any help greatly appreciated.<br>
<br>
            Dan<br>
<br>
<br>
        Sounds like it could be this bug:<br>
<br>
        1.51_3 2015-01-17<br>
<br>
           [BUG FIXES]<br>
<br>
           RT101579 - using bound input parameters for numeric columns (e.g.,<br>
           SQL_NUMERIC) only works the first time and will quite likey fail<br>
           with &quot;string data, right truncation&quot; on the second and subsequent<br>
           calls to execute. Thanks to Laura Cox for finding.<br>
<br>
        What version of DBD::ODBC are you using?<br>
<br>
        What does you perl code look like?<br>
<br>
        Martin<br>
<br>
<br></span>
        ______________________________<u></u>___________________<br>
        unixODBC-support mailing list<br>
        unixODBC-support@mailman.__<a href="http://unixodbc.org" target="_blank">uni<u></u>xodbc.org</a> &lt;mailto:<a href="mailto:unixODBC-support@mailman.unixodbc.org" target="_blank">unixODBC-support@<u></u>mailman.unixodbc.org</a>&gt;<br>
        <a href="http://mailman.unixodbc.org/__mailman/listinfo/unixodbc-__support" target="_blank">http://mailman.unixodbc.org/__<u></u>mailman/listinfo/unixodbc-__<u></u>support</a> &lt;<a href="http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support" target="_blank">http://mailman.unixodbc.org/<u></u>mailman/listinfo/unixodbc-<u></u>support</a>&gt;<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>