FreeTDS Development Group

[Peter Deacon <peterd AT iea-software.com>]

On Tue, 27 Jan 2004, ZIGLIO, Frediano, VF-IT wrote:

> About this change:
> http://cvs.sourceforge.net/viewcvs.py/freetds/freetds/src/odbc/odbc.c?r1
> =1.291&r2=1.292&sortby=date

> I don't really understand the problem and I don't think change is
> correct...

> The only reason SQLDescribeCol should fail with former code is when we
> fetched all results, however why SQLDescribeCol should success in this
> situation? Peter state that this was caused by a empty rowset with a
> numeric but looking at the code and doing some tests do not help
> (problem do not occur).
> current_statement is used to store current statement, if statement is no
> more active it's nosense to still retain old statement. Also issuing
> another query on another statement cause current_statement to change so
> SQLDescribeCol on first statement fails too.
> A better workaround would be to comment these lines in SQLDescribeCol:

I can pretty much reproduce this one at will again, it seems to like
something in my environment... Trying to isolate by calling test queries
hasn't worked so well for me but this definately fixes my problem.

I'm not sure 'when' SQLDescribe col is expected not to work (I assume
until you move on to another statement or free/reset the statement handle,
my docs don't mention this explicitly) but to me it seems if SQLExec
processes TDS_NO_MORE_RESULTS and there is column information, you should
be allowed to call SQLDescribeCol to retreive that information even if
there is no data... since the column information could still be useful to
the application.  Resetting current_statement too early (Inside SQLExec)
pretty much guarantees that won't happen :(

The first thing I tried doing was to modify ODBCDescribe but that idea as
it didn't follow the spirit of how current_statement seemed to have been
being used.

Have Fun!
Peter

>       if (stmt->dbc->current_statement != stmt) {
>               odbc_errs_add(&stmt->errs, "24000", NULL, NULL);
>               ODBC_RETURN(stmt, SQL_ERROR);
>       }
>       IRD_CHECK;
>
> so SQLDescribeCol return data from IRD without any check.
> Naturally it would be better to understand the real problem... why and
> when does SQLDescribeCol fail??
>
> freddy77
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>