Skip to Content.
Sympa Menu

freetds - RE: [freetds] TDS_DONE_TOKEN

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] TDS_DONE_TOKEN
  • Date: Wed, 30 Apr 2003 14:16:05 -0400

> From: ZIGLIO Frediano [mailto:Frediano.Ziglio AT vodafoneomnitel.it]
> Sent: April 30, 2003 11:50 AM
>
> There are some problem that seem to raise at every version of
> FreeTDS : cancelling and done handling
...
> We have 5 state
> TDS_QUERYING,
> TDS_PENDING,
> TDS_COMPLETED,
> TDS_CANCELED,
> TDS_DEAD

Unless you see a difference between QUERYING and PENDING, at first blush it
seems to me they're the same.

TDS_PENDING should be set when the query is sent, it seems to me. We need
that for dbpoll(). We expect and need an answer from the server before we
can send anything else, even if that "answer" is an error message.

TDS_COMPLETED should be TDS_IDLE. Then "if (tds->state != TDS_IDLE)" makes
more sense.

TDS_CANCELED seems like the reasonable state to be in after sending
TDS_BUFSTAT_ATTN, until we're done processing TDS_BUFSTAT_ATTNACK.

> IMHO we should discard result receiving TDS_DONE, not on next
> query. What do you think about?

I don't know. I hope Bill has some insight.

> Also TDS_CMD_DONE is returned for both ending DONE and
> internal DONE (like DONE from statements in RPC). How to
> distinguish the two cases? Test TDS_COMPLETED state?

I don't know. I would rely on the TDS protocol as a guide. You don't get
two DONE tokens, you get DONEINPROC, RETURNSTATUS, DONEPROC. It might be
good to reflect them in libtds. I think ignoring them is likely to be
problematic, as a design choice.

Regards,
--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.





Archive powered by MHonArc 2.6.24.

Top of Page