FreeTDS Development Group

["ZIGLIO Frediano" <Frediano.Ziglio AT vodafone.com>]

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

I'll update it..

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

No, 01 00 -> 0x01 -> no row count.

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

However server return 0 rows... perhaps during the test you did
something wrong... I hope the server return valid informations... I
don't have any workaround for this case :)

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

I don't know... we shouldn't adapt our ctlib to ODBC but our ctlib to
sybase one...

freddy77