Description of problem: If I submit a query to a MSSQL database that is longer than 506 characters, I get the following error: DBD::ODBC::st execute failed: [unixODBC][FreeTDS][SQL Server]Unexpected EOF from the server (SQL-01000) at /share/tech/kconstan/perlTDSTest.pl line 69. Can't execute the SQL statement: [unixODBC][FreeTDS][SQL Server]Unexpected EOF from the server (SQL-01000) at /share/tech/kconstan/perlTDSTest.pl line 69. Version-Release number of selected component (if applicable): How reproducible: Very Steps to Reproduce: 1. Create a query that is 506 characters long, then add a character somewhere to the query. Our queries are asking for many columns in a table which equates to a long query string.
Are you sure that it is freetds issue, not unixODBC or perl one? Please, try to use freetds's tools ("tsql" command) to check whether the direct interaction between the freetds software and MSSQL server have the same issue, or not.
Thanks for the quick response. The query succeeds if run from within tsql. Can you think of a way to narrow down further where the bug might be? Thanks
I installed freetds-0.64-11.fc9, unixODBC-devel-2.2.12-5.fc7, and rebuild perl-DBD_ODBC-1.17-1.rf from the source rpm against these older versions of freetds and unixODBC. The error has changed, but the symptoms are the same. 506 character queries succeed, 507 character queries fail. DBD::ODBC::st execute failed: [unixODBC][FreeTDS][SQL Server]Read from SQL server failed. (SQL-08S01) at /share/tech/kconstan/perlTDSTest.pl.1 line 72. If I install freetds-0.63-1.2.el4.rf.x86_64.rpm, unixODBC-2.2.12-5.fc7.x86_64, and perl-DBD_ODBC-1.17-1.rf, the query succeeds. This leads me to believe that something changed between the two versions of freetds.
> The query succeeds if run from within tsql Well, hence it is either unixODBC or perl-DBD_ODBC issue (or something specific for ".rf" repo). Perhaps something changed in freetds from 0.63 to 0.64 (fe. something became more strict than before), but since tsql works fine, it is not freetds issue. Try to resolve whether direct usage of unixODBC (without perl-DBD_ODBC in front end) or usage by some another front-end failed or not. It should help to undestand where the bug sits (unixODBC vs. perl-DBD_ODBC).
Just for completeness, I found that between 0.63 and 0.64, the freetds rpm's configure line changed from --with-tdsver=7.0 to --with-tdsver="4.2". It appears that perl-DBD-ODBC doesn't look at /etc/odbc.ini, and instead just uses whatever tdsver freetds was compiled with. Passing TDS_Version=7.0 in the connect string in the perl script circumvents the issue. -kevin
FreeTDS had appeared in Fedora since FC6 with version 0.64 already. Ie. already with tdsver of 4.2 . Perhaps some another additional repos (freshrpms and friends) had the version of 0.63 with tdsver set to 7.0 for some its own reasons...