Skip to Content.
Sympa Menu

freetds - [freetds] Re: New BUG: update/delete returns -1 instead of correct affected rows on Merge Publication on MSSQL 2000 SP3a

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "alin" <alin AT intervideo.com>
  • To: freetds AT lists.ibiblio.org
  • Subject: [freetds] Re: New BUG: update/delete returns -1 instead of correct affected rows on Merge Publication on MSSQL 2000 SP3a
  • Date: Fri, 9 Jan 2004 11:40:32 +0200

I think I have something that can help you here. Take a look at
http://jtds.sourceforge.net/TDS.html , the TDS_DONE, TDS_DONEPROC and
TDS_DONEINPROC packets. I did the reverse-engineering quite a while ago, but
I'm 99% sure it's correct. The idea is that the two bytes at offset 3 in the
packet represent the operation, not the transaction state as James said.

What I think is happening in the "bad log" is that the IF at the beginning
of the trigger gets executed (first TDS_DONEINPROC), then the SELECT in the
IF (second TDS_DONEINPROC) and the RETURN (TDS_DONEINPROC); then comes the
return status of the trigger (which is basically a stored procedure) and the
real update count.

jTDS (the JDBC driver based on FreeTDS) goes around this issue by ignoring
TDS_DONEINPROC packets when a simple (non-prepared) statement is executed.
The idea is that the affected rows are always returned in TDS_DONE packets,
TDS_DONEINPROCs in this case come from triggers. However, there's a problem
with prepared statements (which are implemented as temporary stored
procedures): I found no way to make the difference between the trigger (if
it exists) and the values returned by the temporary stored procedure (the
actual statement that interests me). If you find a way to do this, let me
know. ;)

Alin Sinpalean,
the jTDS Project.




  • [freetds] Re: New BUG: update/delete returns -1 instead of correct affected rows on Merge Publication on MSSQL 2000 SP3a, alin, 01/09/2004

Archive powered by MHonArc 2.6.24.

Top of Page