FreeTDS Development Group

["Frediano Ziglio" <freddy77 AT gmail.com>]

2007/7/6, Luke Benstead <kazade AT gmail.com>:
> Hi all,
>
> I've mentioned this on the mailing list before but I haven't worked on
> this
> particular project for a while so haven't attempted to fix the problem..
> anyway...
>
> I am working on a web application that uses PyODBC to connect to MS-SQL.
> One
> certain page on this site crashes Python with the current nightly of
> FreeTDS, yet works perfectly fine with 0.63.
>
> These are the last 2 lines of the freeTDS log when there is an error:
>
> odbc.c:4396:SQLGetData(0x844d548, 12, 1, 0xb6df3608, 2048, 0xb6df3600)
> odbc.c:4396:SQLGetData(0x844d548, 12, 1, 0xb76728ab, -2046, 0xb6df3600)


in src/odbc/odbc.c (SQLGetData):

#ifdef TDS_NO_DM        if (cbValueMax < 0) {                
odbc_errs_add(&stmt->errs,
"HY090", NULL);               ODBC_RETURN(stmt, SQL_ERROR);   }#endif

remove #if/#endif if row and should not core... but caller should
still not call us in such way...

I was previously told that the crash is caused by either PyODBC or unixODBC
> passing in an incorrect buffer length (obviously the negative number is
> wrong) however, simply swapping FreeTDS versions fixes the problem. This
> seems to indicate to me either that its a FreeTDS problem, or that FreeTDS
> used to handle this situation more gracefully than it does now, or perhaps
> FreeTDS does something differently now that causes PyODBC or unixODBC to
> do
> something wrong.
>
> The strange thing is that if I load the page with 0.63 and search the log
> for -2046 it doesn't appear anywhere. I really need to fix this
> because 0.63has another bug elsewhere in the site which is fixed
> later. If you need any
> more information let me know and I'll try to dig it out.
>
> Thanks,
>
> Luke.



bye
 freddy77