FreeTDS Development Group

["Peter C. Norton" <spacey-freetds.org AT ssr.com>]

It looks like the sybase server will return something other than
SQL_SUCCESS, then.  This is against the following Sybase ASE:

        Adaptive Server Enterprise/15.0.3/EBF 17166 ESD#3/P/Solaris AMD64/OS 
5.10/ase1503/2726/64-bit/FBO/Fri Feb  5 02:16:02 2010

Would a dump/trace of the tds session contain an indication of the
return value, or do I need to re-enable this code and attach with a
debugger?

-Peter

On Tue, Oct 19, 2010 at 09:08:10AM +0200, Frediano Ziglio wrote:
> 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 <spacey-freetds.org AT ssr.com>:
> > 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
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds