FreeTDS Development Group

["alin" <alin AT intervideo.com>]

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.