FreeTDS Development Group

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

> From: ZIGLIO Frediano [mailto:Frediano.Ziglio AT vodafone.com]
> Sent: January 9, 2004 5:05 AM
> > 
> > The good one, freetds.log.ok:
> > 
> > Received packet @ 2004-01-08 20:06:13.782263
> > 0000  fd            <= TDS_DONE
> >          10 00              <= 0x0010, done count valid 
> >            c5 00    <= transaction state ??
> >                  01 00 00 00 <= 0x0001 row affected
> > 
> 
> This is not transaction state but statement executed (0xC5 update 0xC1
> select)

Ah.  Very different from TDS 5.0.  It would be very helpful if you or Bill
could update the protocol document.  Reverse-engineered information is very
hard-won, and not easy to extract from the code.  For my part, I'm going to
convert it to DocBook, leaving it in its own file.  We can include it in the
UG and share it with Alin and the other jTDS folks.  

> > The bad one, freetds.log.debug:
> > 
> > Received packet @ 2004-01-08 19:52:58.992128
> > 0000  ff            <= TDS_DONEINPROC  
> >          01 00              <= 0x0010, done count valid 
> >            c0 00    <= transaction state 0x00c0 ?? (OK....)
> >                  00 00 00 00 <= zero rows affected
> >                  
> 
> 0x01 is just more coming without row. In ODBC I ignore this 
> token (as MS does)

OK, I think you're referring to the packet below, not above?  

> >       ff    <= TDS_DONEINPROC  
> >          11 00      <= 0x0011, done count valid, more coming 
> >                c1 00        <= transaction state 0x00c1 ?? (OK....)
> >                  01 00 00 00 <= 0x0001 row affected
> 
> This is a count inside a procedure, also ignored by ODBC 
> cause there is no row.

Is this right:

1.  0xC1 marks it as SELECT
2.  TDS_DONEINPROC marks it as "inside a procedure"

Would this packet be affected by "set nocount on"?  

> >       ff            <= TDS_DONEINPROC   
> >          01 00              <= 0x0010, done count valid  
> >            00 00    <= transaction state zero
> >                  00 00 00 00  <= zero rows affected
> 
> 0x00 ?? However there is no rowcount.

Perhaps 0x00 refers to something internal, not select/insert/update?

> >       79            <= TDS_RETURNSTATUS   
> >          00 00 00 00        <= procedure returned zero
> >      
> > 0020  fd            <= TDS_DONE
> >          10 00              <= 0x0010, done count valid 
> >            c5 00    <= transaction state ??
> >                  00 00 00 00   <= zero rows affected       
> > 
> 
> 0xC5 is update, our statement and 0 rows are returned. So 0 would be
> returned by ODBC.

Am I to understand that this update statement affected no rows?   The "good
log" update affected 1 row.  

I'm pretty sure the answer is Yes, but I want to confirm.  

> > Not quite the same, you know?  ;-)
> 
> No :) ODBC should return (correctly 0) however I don't know the CTLib
> behaviour in this situation... our FreeTDS return even TDS_DONEINPROC
> however I don't know the expected behavior (that is the Sybase CTLib
> bahavior)...

That's good news, actually.  One, you understand the protocol at this level,
and libtds interprets it accurately.  There may be some impedance mismatch
in the ct-lib/libtds interface, leading me to suppose perhaps the logic
isn't sufficiently encapsulated in libtds.  

It sounds like it's "merely" a matter of adapting to ct-lib what's already
done in ODBC.  Whew!  

Thanks for the explanation, Freddy.  

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