FreeTDS Development Group

["Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>]

Thanks James,

> Your version is highly dangerous IMO.  Safer would have been to call
> dbcanquery() before tds_send_cancel().  That would have discarded genuine
> rows, not just anything the server happened to send.  But that begs the
> question of why tds_send_cancel() isn't good enough.  

except the sybase dblibrary manual says that is exactly what dbcancel
does...

I don't see the danger myself. An application has the choice of whether to
call dbcanquery or dbcancel.
They do different things. According to the Sybase manual page for
dbcanquery, it is called to: 

"Cancel any rows pending from the most recently executed query."

this manual page also states:

"If you want to ignore all of the results from all of the commands in the
current command batch, call dbcancel instead."

IMHO, we now do what it says on the tin.

Until not so long ago (3 weeks or so), and since time immemorial (as far as
I can tell) we were doing this at the top of dbsqlexec():
 
if (tds->res_info && tds->res_info->more_results) {
        dbresults(dbproc);
}

I think this code was probably attempting to achieve much the same as my
patches, although with larger boots on!

Bill

> -----Original Message-----
> From: Lowden, James K [SMTP:LowdenJK AT bernstein.com]
> Sent: 05 March 2003 15:46
> To:   'FreeTDS Development Group'
> Subject:      RE: [freetds] Comment on change
> 
> > From: ZIGLIO Frediano [mailto:Frediano.Ziglio AT vodafoneomnitel.it]
> > Sent: March 5, 2003 9:56 AM
> > 
> > @  dbcancel(DBPROCESS * dbproc)
> > @  {
> > @ +int marker;
> > @ +TDSSOCKET *tds;
> > @ +
> > @ + tds = (TDSSOCKET *) dbproc->tds_socket;
> > @ +
> > @ + while (tds->state != TDS_COMPLETED ) {
> > @ + 
> > @ +         marker = tds_get_byte(tds);
> > @ +
> > @ +         tdsdump_log(TDS_DBG_INFO1, "%L dbcancel() discarding
> > results. marker is %x\n", marker);
> > @ + 
> > @ +         if (tds_process_default_tokens(tds, marker) == 
> > TDS_FAIL) 
> > @ +                 return TDS_FAIL;
> > @ + }
> > @ +
> > @   tds_send_cancel(dbproc->tds_socket);
> > @   tds_process_cancel(dbproc->tds_socket);
> > @   return SUCCEED;
> > @  }
> > @  
> > 
> > ?? skipping data instead to send a proper cancel is quite 
> > bad... if server
> > is returning huge amount of data cancel take ages.... IMHO 
> > libtds (token.c)
> > should be encharge for processing cancel, not dblib.
> 
> Bill, what was the motivation here?  Do you have an example of a query or
> situation where 
> dbcancel(DBPROCESS * dbproc)
> {
>         tds_send_cancel(dbproc->tds_socket);
>         tds_process_cancel(dbproc->tds_socket);
>         return SUCCEED;
> }
> 
> is insufficient?  If so, I'd like to address it in libtds, as Freddy
> suggests.  
> 
> Your version is highly dangerous IMO.  Safer would have been to call
> dbcanquery() before tds_send_cancel().  That would have discarded genuine
> rows, not just anything the server happened to send.  But that begs the
> question of why tds_send_cancel() isn't good enough.  
> 
> --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.
> 
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds