Skip to Content.
Sympa Menu

freetds - Re: [freetds] problem with ct_dynamic(....CS_PREPARE...) against SQL Server 2005

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] problem with ct_dynamic(....CS_PREPARE...) against SQL Server 2005
  • Date: Sat, 7 Mar 2009 12:04:51 -0500

ocfs2 AT asset-control.com wrote:
> net.c:671:Received packet
> 0000 ff 01 00 c0 00 00 00 00-00 ff 11 00 c5 00 01 00 |........ ........|
> 0010 00 00 ff 11 00 c3 00 01-00 00 00 ff 11 00 c3 00 |........ ........|
> 0020 01 00 00 00 79 00 00 00-00 fe 00 00 e0 00 00 00 |....y... ........|
> 0030 00 00 - |..|
...
> token.c:510:processing result tokens. marker is 79(RETURNSTATUS)
> token.c:510:processing result tokens. marker is fe(DONEPROC)
> token.c:2201:tds_process_end: more_results = 0
> was_cancelled = 0
> error = 0
> done_count_valid = 0
> token.c:2217:tds_process_end() state set to TDS_IDLE
...
> util.c:110:logic error: cannot change query state from IDLE to PENDING

(Don't worry about this unless you really want to dig into the guts of the
TDS state machine. It doesn't seem to affect functionality. Somewhere,
we're failing to track the server's state precisely. Tracking state helps
prevent protocol violations stemming from API misuse, and to present
useful error messages.)

> ct.c:1157:ct_results() process_result_tokens returned 1 (type 4053)
> ct.c:2357:ct_res_info()
> ct.c:2382:ct_res_info(): Number of rows is -1
...
> However the last (DONEPROC) token does not contain a valid done_count,
> and therefore inside tds_process_end() tds->rows_affected is reset to
> TDS_NO_COUNT.
...
> A quick fix would be to remove the else part near the bottom of
> tds_process_end(),
> so a valid affected rows count does not get overwritten....

http://www.freetds.org/tds.html#t255

Er, no, that wouldn't be a fix. The server said in its status word that
there is no row count. The protocol provides for 32/64 bits of rowcount
information in every DONEPROC packet, but doesn't require that the value
therein be valid. So, sure, you can grab the value, but it won't be the
number of rows affected except 1 time in 2^32.

DONE packet processing rules are quite complicated. Cf
http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-TDS%5D.pdf
if you want lots of detail.

HTH.

--jkl






Archive powered by MHonArc 2.6.24.

Top of Page