[freetds] Problems with UnixODBC and FreeTDS
Frediano Ziglio
freddy77 at gmail.com
Tue Jul 10 06:42:38 EDT 2007
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
More information about the FreeTDS
mailing list