Skip to Content.
Sympa Menu

freetds - RE: [freetds] Strange code

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO Frediano" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Strange code
  • Date: Mon, 3 Nov 2003 18:01:42 +0100

You catch quite well. But consider the case of two (and not one)
recordset. I need the DONE packet from both recordset, not only at
DONEPROC. As you said correct rows are returned from DONEINPROC so why
wait DONEPROC ? Perhaps is better to read ahead in case of DONEINPROC
and process RETURNSTATUS and DONEPROC. Well... you don't know ODBC that
much.. SQLExecute call tds_submit_execute that send a sp_execute call.

So, a "select * from table select * from table" when table is empty
returns:

TDS_ROWFMT_TOKEN first recordset with column information
TDS_DONEINPROC_TOKEN 0 rows returned from first recordset
TDS_ROWFMT_TOKEN second recordset with column information
TDS_DONEINPROC_TOKEN 0 rows returned from second recordset
TDS_RETURNSTATUS sp_executesql RPC status
TDS_DONEPROC_TOKEN sp_executesql done

IMHO is better to "ignore" (do not return to client) RETURNSTATUS and
DONEPROC, not DONEINPROC (equivalent to a DONE without sp_executesql).

freddy77


>
> Sorry Freddy,
>
> I don't 100% understand where the problem is...
>
> are you saying that your code in SQLExecute is EXPECTING to
> get a DONEINPROC returned ?
>
> The whole point of my change was to hide the fact that an
> internal sp was called from whatever is calling
> tds_process_result_tokens().
>
> When some internal sp's are called - sp_cursorfetch in my
> case - the "rows affected" count that we want is returned on
> the DONEINPROC token from the "hidden" stored procedure call.
> My change was INTENDED to save this value and then return it
> to the calling function when TDS_DONEPROC was encountered -
> cunningly altering the result type so that TDS_DONE_RESULT is
> returned instead of TDS_DONEPROC_RESULT.
>
> The calling code could then theoretically work against TDS 5
> and TDS 7 , getting the same sequence of result types from
> tds_process_result_tokens() in both cases...
>
> have I understood the problem correctly , and explained
> myself ? If not please say so....
>
>
> Bill
>
>
>
>
> > -----Original Message-----
> > From: ZIGLIO Frediano [SMTP:Frediano.Ziglio AT vodafone.com]
> > Sent: 03 November 2003 14:11
> > To: freetds AT lists.ibiblio.org
> > Subject: [freetds] Strange code
> >
> > Doing some tests with ODBC I doscovered a small problem with token.c
> >
> > Calling SQLExecute with a query like "select * from table select *
> > from table" (two rowset) where table is empty mssql return
> >
> > TDS_ROWFMT_TOKEN
> > TDS_DONEINPROC_TOKEN
> > TDS_ROWFMT_TOKEN
> > TDS_DONEINPROC_TOKEN
> > TDS_RETURNSTATUS
> > TDS_DONEPROC_TOKEN
> >
> > With this code (taken from token.c):
> >
> > case TDS_DONEINPROC_TOKEN:
> > /* FIXME should we free results ?? */
> > tds_process_end(tds, marker, done_flags);
> > if (tds->internal_sp_called) {
> > if (tds->rows_affected != TDS_NO_COUNT)
> > {
> > saved_rows_affected =
> > tds->rows_affected;
> > }
> > } else {
> > *result_type = TDS_DONEINPROC_RESULT;
> > return TDS_SUCCEED;
> > }
> > break;
> >
> > DONEINPROC is not returned... This break t0003 test on ODBC (cause
> > code detect only one recordset instead of two). I know that
> this code
> > came from cursor change however I don't know cursor
> protocol that much
> > to remove it. In sp_execute case we should remove TDS_DONEPROC, not
> > TDS_DONEINPROC.
> >




Archive powered by MHonArc 2.6.24.

Top of Page