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: "Luke Benstead" <kazade AT gmail.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Problems with UnixODBC and FreeTDS
  • Date: Mon, 9 Jul 2007 17:26:33 +0100

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...
>
> freddy77
>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>






Archive powered by MHonArc 2.6.24.

Top of Page