FreeTDS Development Group

["Luke Benstead" <kazade AT gmail.com>]

I've managed to work out exactly when it crashes. If you select a text field
that is blank (i.e not NULL but empty) it crashes, here is the minimal
python code:

import pyodbc

if __name__ == '__main__':
   strSQL="""
SELECT BlankField FROM SomeTable
   """
   cnxn = pyodbc.connect
('DRIVER={FreeTDS};SERVERNAME=server;DATABASE=db;UID=user;PWD=password')
   cursor = cnxn.cursor()
   cursor.execute(strSQL)
   print cursor.fetchall()

Hope that helps.

Luke.

On 10/07/07, Frediano Ziglio <freddy77 AT gmail.com> wrote:
> 2007/7/9, Luke Benstead <kazade AT gmail.com>:
> >
> > I noticed that the 0.63 version was not logging SQLGetData calls, so I
> > added
> > that so you can compare the logs. This is the one from 0.63:
> >
> > 17:23:55.761437 SQLGetData(0x83229c8, 1, 1, 0xb6bc3608, 2048,
> 0xb6bc3600)
> > 17:23:55.761449 convert_tds2sql: src is 39 dest = 1
> > 17:23:55.761460 convert_tds2sql: outputting character data destlen =
> 2048
> > 17:23:55.761474 SQLGetData(0x83229c8, 2, 1, 0xb6bc3608, 2048,
> 0xb6bc3600)
> > 17:23:55.761486 convert_tds2sql: src is 39 dest = 1
> > 17:23:55.761497 convert_tds2sql: outputting character data destlen =
> 2048
> > 17:23:55.761511 processing row tokens.  marker is  ff(DONEINPROC)
> > 17:23:55.761523 tds_process_end: more_results = 1
> >        was_cancelled = 0
> >        error = 0
> >        done_count_valid = 1
> > 17:23:55.761535                 rows_affected = 170
> > 17:23:55.761553 SQLFetch: NO_DATA_FOUND
> >
> > Luke.
> >
> > On 09/07/07, Luke Benstead <kazade AT gmail.com> wrote:
> > >
> > > OK, well I tried again with the last nightly and it crashed again, the
> > log
> > > is slightly different, here is the last part:
> > >
> > > odbc.c:4414:SQLGetData(0x843c0f8, 11, 1, 0x84873b4, 37, 0xb6bc3600)
> > > convert_tds2sql.c:62:convert_tds2sql: src is 36 dest = 1
> > > convert_tds2sql.c:131:convert_tds2sql: outputting character data
> destlen
> > =
> > > 37
> > > odbc.c:4414:SQLGetData(0x843c0f8, 12, 1, 0xb6bc3608, 2048, 0xb6bc3600)
> > > convert_tds2sql.c:62:convert_tds2sql: src is 39 dest = 1
> > > convert_tds2sql.c:131:convert_tds2sql: outputting character data
> destlen
> > =
> > > 2048
> > > odbc.c:4414:SQLGetData(0x843c0f8, 13, 1, 0xb6bc3608, 2048, 0xb6bc3600)
> > > convert_tds2sql.c:62:convert_tds2sql: src is 35 dest = 1
> > > convert_tds2sql.c:131:convert_tds2sql: outputting character data
> destlen
> > =
> > > 2048
> > > odbc.c:4414:SQLGetData(0x843c0f8, 14, 1, 0xb6bc3608, 2048, 0xb6bc3600)
> > > odbc.c:4414:SQLGetData(0x843c0f8, 14, 1, 0xb74468ab, -2046,
> 0xb6bc3600)
> > > error.c:613:SQLGetDiagRec(3, 0x843c0f8, 1, 0xb6bc325a, 0xb6bc3268,
> > > 0xb6bc305a, 512, 0xb6bc3264)
> > > error.c:514:_SQLGetDiagRec(3, 0x843c0f8, 1, 0xb6bc325a, 0xb6bc3268,
> > > 0xb6bc305a, 512, 0xb6bc3264)
> > > error.c:613:SQLGetDiagRec(3, 0x843c0f8, 2, 0xb6bc325a, 0xb6bc3268,
> > > 0xb6bc305a, 512, 0xb6bc3264)
> > > error.c:514:_SQLGetDiagRec(3, 0x843c0f8, 2, 0xb6bc325a, 0xb6bc3268,
> > > 0xb6bc305a, 512, 0xb6bc3264)
> > > error.c:613:SQLGetDiagRec(3, 0x843c0f8, 1, 0xb6bc3170, 0xb6bc3180,
> > > 0xb6bc3188, 1023, 0xb6bc3186)
> > > error.c:514:_SQLGetDiagRec(3, 0x843c0f8, 1, 0xb6bc3170, 0xb6bc3180,
> > > 0xb6bc3188, 1023, 0xb6bc3186)
> > >
> > > I appreciate that it is likely that the DM is passing an incorrect
> > value,
> > > however this doesn't explain why the error doesn't occur with a
> previous
> > > version of FreeTDS. I mean, with 0.63 a negative value doesnt even
> > appear
> > > in the log and everything else is the same (i.e. code, pyODBC and
> > > unixODBC) the only thing different is FreeTDS. Also the same code
> works
> > > perfectly on Windows.
> > >
> > > Another thing that seems odd to me in the log is that there is a load
> of
> > > lines like this:
> > >
> > > odbc.c:4414:SQLGetData(0x843c0f8, 11, 1, 0x84873b4, 37, 0xb6bc3600)
> > > << Get Data
> > > convert_tds2sql.c:62:convert_tds2sql: src is 36 dest =
> > > 1                                 << do something
> > > convert_tds2sql.c:131:convert_tds2sql: outputting character data
> destlen
> > =
> > > 37  <<do something else
> > > odbc.c:4414:SQLGetData(0x843c0f8, 12, 1, 0xb6bc3608, 2048, 0xb6bc3600)
> > > << Get Data again
> > > convert_tds2sql.c:62:convert_tds2sql: src is 39 dest =
> > > 1                                 << Rinse and repeat
> > > convert_tds2sql.c:131:convert_tds2sql: outputting character data
> destlen
> > =
> > > 2048
> > >
> > > then all of a sudden:
> > >
> > > odbc.c:4414:SQLGetData(0x843c0f8, 14, 1, 0xb6bc3608, 2048, 0xb6bc3600)
> > <<
> > > GetData
> > > odbc.c:4414:SQLGetData(0x843c0f8, 14, 1, 0xb74468ab, -2046,
> 0xb6bc3600)
> > <<
> > > GetData again??
> > >
> > > Why doesn't it do the convert_tds2sql stuff again? Why straight back
> to
> > > SQLGetData? I don't know how this works but it looks a bit suspicious
> to
> > me.
> > >
> > > If anyone can give me any more help in solving this problem I'd
> > appreciate
> > > it.
> > >
> > > Thanks
> > >
> > > Luke.
> > >
> > >
> > > On 07/07/07, Frediano Ziglio <freddy77 AT gmail.com> wrote:
> > > >
> > > > Il giorno ven, 06/07/2007 alle 20.57 -0400, James K. Lowden ha
> > scritto:
> > > > > Frediano Ziglio wrote:
> > > > > > > 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...
> > > > >
> > > > > Freddy, why wrap error checking in #ifdef TDS_NO_DM?  Seems to me
> > it's
> > > > > *always* better to check inputs for validity.
> > > > >
> > > >
> > > > This parameter should be checked by DM... removed.
> > > > I still don't understand why 0.63 didn't core...
> > > >
>
>
> The problem could be that first SQLGetData for some reasons return
> SQL_ERROR. Could you please post small python snippet ??
>
> I think these lines
>
>     char ab[MAX_VAR_STACK];
>
>     cbData = 0;
>     ret = SQLGetData(cur->hstmt, (SQLSMALLINT)(iCol+1), nTargetType, ab,
> MAX_VAR_STACK, &cbData);
>     if (ret == SQL_SUCCESS)
>
> should be changed to
>
>     char ab[MAX_VAR_STACK];
>
>     cbData = 0;
>     ret = SQLGetData(cur->hstmt, (SQLSMALLINT)(iCol+1), nTargetType, ab,
> MAX_VAR_STACK, &cbData);
>     if (!SQL_SUCCEEDED(ret))
>         return RaiseErrorFromHandle(GetConnection(cur)->hdbc, cur->hstmt);
>
>     if (ret == SQL_SUCCESS)
>
> freddy77
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds