FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Frediano Ziglio [mailto:freddyz77 AT tin.it]
> Sent: March 5, 2003 2:52 PM
> > 
> > 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.  
> 
> I don't think is possible to cancel half store procedure 

Indeed it is, see attached (not beautiful, but illustrative).  It installs a
stored procedure that returns two batches, executes it, then calls
dbcancel() after it gets the first row.  

On my system, there are 478 rows in sysobjects in this particular database.
Looking at the wire with windump (tcpdump for the OS-impaired), I see the
cancel honored long before the last row would have been sent:

0x0370   0000 0400 0000 0002 0000 d111 5064 5365        ............PdSe
0x0380   6375 7269 7479 4861 6e64 6c65 7314 f3b5        curityHandles...
0x0390   7f02 5520 0100 0800 2300 8000 3b00 0000        ..U.....#...;...
0x03a0   0000 0000 0000 0000 258f 0000 9432 c500        ........%....2..
0x03b0   0000 3000 0000 0b00 0000 0255 2002 0100        ..0........U....
0x03c0   0273 0002 0000 0825 8f00 0094 32c5 0004        .s.....%....2...
0x03d0   0000 0000 0400 0000 0004 0000 0000 0400        ................
0x03e0   0000 0004 0000 0000 0401 0000 0002 0000        ................
0x03f0   d10a 7073 7461 6e6e 3833 5f33 9ddb e07f        ..pstann83_3....
0x0400   0255 2001 003c 0001 0000 0015 0000 0000        .U...<..........
0x0410   0000 0000 0000 00f1 9100 00de 24fb 0000        ............$...
0x0420   0010 0000 0005 0000 0002 5520 0201 0002        ..........U.....
0x0430   5300 0200 0008 f191 0000 de24 fb00 0400        S..........$....
0x0440   0000 0004 0000 0000 0400 0000 0004 0000        ................
0x0450   0000 0400 0000 0004 0000 0000 0200 00fd        ................
0x0460   2000 e000 e201 0000                            ........

Using Microsoft's db-lib, none of the spurious rows is returned to the
application, and the result set it truncated as soon as the server gets
around to it.  

> One of my intentions 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.

That would be a vast improvement.  libtds needs kernel-type treatment:
top-half callable by client libraries, bottom-half touches the wire (and
deals in tokens).  Eventually, we should pass whole TDS packets around,
instead of tokens and raw buffers.  

As I've become familiar with the TDS 5.0 spec and ct-lib, I've noticed that
ct-lib functions map neatly onto the protocol.  That suggests to me that
ct-lib is a good model for the libtds interface.  

--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.

Attachment: dbsql.c
Description: Binary data