Skip to Content.
Sympa Menu

freetds - [freetds] done processing and token.c

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: [freetds] done processing and token.c
  • Date: Wed, 12 Jan 2005 17:42:41 +0100

Today I started fixing problem using compute results.

Mainly in token.c there are 5 function to process tokens
tds_process_cancel
tds_process_result_tokens
tds_process_row_tokens
tds_process_row_tokens_ct
tds_process_trailing_tokens
(I removed tds_do_until_done just some minutes ago... it was not used
anymore)

Main differences are in how DONE tokens are handled. For example
tds_process_row_tokens handle DONE while tds_process_row_tokens_ct
don't. I don't remember who but someone reported that in ODBC it seems
that MS driver accept query after last SUCCESS SQLFetch (that is if you
have a simple select query which return 3 rows after reading 3 rows you
can issue another query). Our ODBC behave differently. From dblib source
it seems that even dblib should read trailing token

if (dbproc->tds_socket->state == TDS_PENDING) {

if (tds_process_trailing_tokens(dbproc->tds_socket) !=
TDS_SUCCEED) {
_dblib_client_msg(dbproc, 20019, 7, "Attempt to initiate a
new SQL Server operation with results pending.");
dbproc->command_state = DBCMDSENT;
return FAIL;
}
}

(code from dbwritetext and dbsqlsend, even dbnumrets use similar code
and I added tds_process_trailing_tokens call to ODBC too to handle
compute correctly)

As usually I never liked the use of tds_peek/tds_get_byte and similar in
higher libraries. During the coding of compute (not in final code
however) I added the use of tds_peek too. It seems that in some case
it's useful to read only some type of tokens (for example only rows in
ct_fetch/SQLFetch or skip DONE* in dbsqlok).

I think that it would fine to define a unique function that:
- handle some fixed token trasparently (TDS_RETURNSTATUS_TOKEN, param
tokens)
- handle or just return (selecting behavior with a flag) the type of
other tokens. For example I would define some class:
- metadata (ROWFMT, COMPUTEFMT)
- param
- normal row
- compute row
- status ??

This would also fix another problem raised during debug. Calling
tds_process_row_tokens* on a metadata token it fails with an "Unknown
marker" cause tds_process_default_tokens do not handle all tokens (I
think that this can also happen calling tds_process_cancel.. not that
fine).

freddy




Archive powered by MHonArc 2.6.24.

Top of Page