Skip to Content.
Sympa Menu

freetds - [freetds] Commit to odbc.c from 5/19/2010 breaks prepared statements with pyodbc

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Peter C. Norton" <spacey-freetds.org AT ssr.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: [freetds] Commit to odbc.c from 5/19/2010 breaks prepared statements with pyodbc
  • Date: Fri, 15 Oct 2010 13:58:45 -0400

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







Archive powered by MHonArc 2.6.24.

Top of Page