Skip to Content.
Sympa Menu

freetds - Re: [freetds] Problems with UnixODBC and FreeTDS

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Frediano Ziglio" <freddy77 AT gmail.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Problems with UnixODBC and FreeTDS
  • Date: Tue, 10 Jul 2007 12:42:38 +0200

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




Archive powered by MHonArc 2.6.24.

Top of Page