FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

A debugger is not nevessary. In this case a DM (unixODBC in your case)
trace would be ok. A FreeTDS dump is also ok.

Regards
  Frediano

Il giorno mar, 19/10/2010 alle 11.42 -0400, Peter C. Norton ha scritto:
> 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
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds