FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

> > I don't see the danger myself. An application has the choice 
> > of whether to call dbcanquery or dbcancel.
> > They do different things. 
> 
> Indeed.  A stored procedure may return N result sets.  dbcancel() will
> cancel them all, returning the protocol to an idle state.  dbcanquery()
> cancels only the current result set, queuing up the next one.  
> 
> Doesn't your code attempt the effect of cancelling the current query (by
> reading until TDS_COMPLETED) and then cancelling any successors?  I was just
> suggesting we don't need another packet-reading loop in db-lib, particuarly
> one that does the same thing AIUI as dbcanquery().  
> 

I don't think is possible to cancel half store procedure (we should
try)...
Perhaps subtle difference it this: an application can add many query and
then post with a single send. With dbcanquery ctlib cancel current query
and continue with next in queue while with dbcancel cancel current query
and free the queue...

One of my intention for 0.62 is to cleanup all improper wire use. High
level libraries should only call libtds without any token or byte
knowledge. For example consider modified dbsqlsend. Instead of handling
some token just call tds_process_result_tokens; this function do not
read row data and process all other results. The same of current
implementation..

freddy77