FreeTDS Development Group

["Mark J. Lilback" <mark AT lilback.com>]

Using the latest cvs source, I'm getting a strange result from 
ct_res_info after sending an insert query -- 262144 doesn't seem like 
it is what should be returned. I'm using TDS 7 to connect to MS SQL 
Server 7 SP3.

From the tds protocol documentation in tds.html, the packet looks 
correct. What I'm getting from ct_res_info isn't, however.

Walking through the code, ct_res_info is deciding the value to return 
based on tds->curr_resinfo existing. From what I can tell, this is 
never set or cleared in any of the calls from ct_results() through 
ct_res_info(). That appears to be the problem.

My best guess is that tds_process_result_tokens() needs to set 
tds->curr_resinfo to NULL at the start and then let it get set as 
needed. A number of functions called from tds_process_result_tokens 
set it.

Thoughts and opinions?

In limited testing it doesn't seem to cause any problems for me, and 
I now get an accurate count of rows affected by insert/update/delete 
statements.



Here's the dump file contents for this query.


2003-02-22 11:58:35.783619 inside ct_cmd_alloc()
2003-02-22 11:58:35.783900 inside ct_command()
2003-02-22 11:58:35.783994 inside ct_send()
Sending packet @ 2003-02-22 11:58:35.784101
0000  01 01 00 c4 00 00 01 00  69 00 6e 00 73 00 65 00   |........ i.n.s.e.|
0010  72 00 74 00 20 00 69 00  6e 00 74 00 6f 00 20 00   |r.t. .i. n.t.o. .|
0020  70 00 72 00 6f 00 64 00  75 00 63 00 74 00 20 00   |p.r.o.d. u.c.t. .|
0030  28 00 6e 00 61 00 6d 00  65 00 2c 00 70 00 72 00   |(.n.a.m. e.,.p.r.|
0040  69 00 63 00 65 00 2c 00  63 00 61 00 74 00 65 00   |i.c.e.,. c.a.t.e.|
0050  67 00 6f 00 72 00 79 00  29 00 20 00 76 00 61 00   |g.o.r.y. ). .v.a.|
0060  6c 00 75 00 65 00 73 00  20 00 28 00 27 00 57 00   |l.u.e.s.  .(.'.W.|
0070  69 00 64 00 67 00 65 00  74 00 20 00 57 00 69 00   |i.d.g.e. t. .W.i.|
0080  66 00 65 00 20 00 53 00  77 00 65 00 61 00 74 00   |f.e. .S. w.e.a.t.|
0090  73 00 68 00 69 00 72 00  74 00 27 00 2c 00 20 00   |s.h.i.r. t.'.,. .|
00a0  32 00 30 00 2e 00 30 00  30 00 2c 00 20 00 27 00   |2.0...0. 0.,. .'.|
00b0  63 00 6c 00 6f 00 74 00  68 00 69 00 6e 00 67 00   |c.l.o.t. h.i.n.g.|
00c0  27 00 29 00                                        |'.).|


2003-02-22 11:58:35.785277 ct_send() succeeded
2003-02-22 11:58:35.785411 inside ct_results()
Received header @ 2003-02-22 11:58:35.791452
0000  04 01 00 11 00 00 00 00                            |........|


Received packet @ 2003-02-22 11:58:35.791695
0000  fd 10 00 c3 00 01 00 00  00                        |........ .|


2003-02-22 11:58:35.791800 processing result tokens.  marker is  fd(DONE)
2003-02-22 11:58:35.791878 inside tds_process_end() more_results = 0, 
was_cancelled = 0
2003-02-22 11:58:35.791955 inside ct_results() process_result_tokens 
returned 1 (type 4046)
2003-02-22 11:58:35.792037 inside ct_res_info()
2003-02-22 11:58:35.792109 ct_res_info(): Number of rows is 262144
2003-02-22 11:58:35.792182 inside ct_cancel()
2003-02-22 11:58:35.792253 inside ct_results()
2003-02-22 11:58:35.792323 inside tds_process_result_tokens() state 
is COMPLETED
2003-02-22 11:58:35.792394 inside ct_results() process_result_tokens 
returned 2 (type 4046)
2003-02-22 11:58:35.792467 inside ct_cmd_drop()

--
__________________________________________________________________________
                                  "They that can give up essential liberty
Mark J. Lilback                    to obtain a little temporary safety
<mark AT lilback.com>                 deserve neither liberty or safety."
http://www.lilback.com/                               -- Benjamin Franklin