Skip to Content.
Sympa Menu

freetds - RE: [freetds] New BUG: update/delete returns -1 instead ofcorrectaffected rows on Merge Publication on MSSQL 2000 SP3a

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO Frediano" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] New BUG: update/delete returns -1 instead ofcorrectaffected rows on Merge Publication on MSSQL 2000 SP3a
  • Date: Fri, 9 Jan 2004 18:11:12 +0100


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



  • RE: [freetds] New BUG: update/delete returns -1 instead ofcorrectaffected rows on Merge Publication on MSSQL 2000 SP3a, ZIGLIO Frediano, 01/09/2004

Archive powered by MHonArc 2.6.24.

Top of Page