Re: Commit to odbc.c from 5/19/2010 breaks prepared statements with pyodbc
Frediano Ziglio <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
The patch add lazy prepare which improve performance and works better with DBD::ODBC. If I understood correctly using mssql works correct but with Sybase server the results is not ok. Am I right? The correct solution is fix the issue using Sybase. freddy77 2010/10/15 Peter C. Norton <[email protected]>: > Hi, I've got another bug report. At my site we've run into a > regression when going from the following: > > pyodbc-2.1.7 > depends on > unixODBC-2.2.14 > which depends on > freetds-0.82.1.dev.20091223 > > to the same pyodbc and unixODBC, but upgrading to > freetds-0.83.dev.20100902 + various patches from upstream. When users > tested it I got the following succinct bug report: > > import pyodbc > def the_test(db_name): > db = pyodbc.connect("DSN=%s;UID=<USERNAME>;PWD=<PASSWORD>;DATABASE=<any database>;APP=python_test" % db_name) > q = db.execute("select * from <any table> where type = ?", (1,)) > print q.fetchall() > > the_test("SYBASE") > > results in the following error: > > Error: ('HY000', 'The driver did not supply an error!') > > Confirmed on solaris x86 and linux/64-bit. I've bisected the changes > made back to 5/19/2010 via the freetds git repository and I found that > the following broke prepared statements from pyodbc: > > http://github.com/brianb/FreeTDS/commit/2ed78ea4dd9018927b56822e318e0b5ac9401b98#diff-2 > > Specifically the chunk between line 1301 and 1313. The relevent chunk of code is this: > > if (desc->type == DESC_IRD && ((TDS_STMT*)desc->parent)->need_reprepare && \ > odbc_update_ird((TDS_STMT*)desc->parent, errs) != SQL_SUCCESS) \ > exit; \ > > Reverting the patch to the pre-2010-05-19 state has the preprocessor > replace the above with: > > #define IRD_UPDATE(desc, errs, exit) do { } while(0) > > which may just be masking an error, but I do not know. Backing this > out causes prepared statements to work again. Are there any gotchas > to reverting this change? And is there a better/more correct fix for > this? > > By the way, this works fine when I point the same test an an MSSQL 2005 or 2008 server. > > Thanks, > > -Peter > _______________________________________________ FreeTDS mailing list [email protected] http://lists.ibiblio.org/mailman/listinfo/freetds