FreeTDS Development Group

["Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>]

Hi,

I can't really understand what's going on here.

here's what you get back from the server in "reply" to your update
statement.

Received packet @ 2003-08-06 08:52:40.965880
0000  ff 45 00 d4 00 00 00 00  00 ff 55 00 c1 00 01 00   |.E...... ..U.....|
0010  00 00 ff 55 00 c1 00 01  00 00 00 ff 45 00 c0 00   |...U.... ....E...|
0020  00 00 00 00 ff 55 00 c5  00 01 00 00 00 ff 45 00   |.....U.. ......E.|
0030  d5 00 00 00 00 00 fd 10  00 c5 00 01 00 00 00      |........ .......|

First up, you have 6 DONEINPROC tokens (starting 0xff )
I imagine the update is firing some triggers, or somesuch. I can't think of
any other reason for these coming back.
No matter, you then get the DONE token (0xfd)

fd 10  00 c5 00 01 00 00 00      

The first two bytes indicate that the "done count" is valid, and the last 4
bytes are the "done count" , which is 1 (4 byte integer, little endian)

you clearly do process this information, viz:

2003-08-06 08:52:40.966728 inside ct_results()
2003-08-06 08:52:40.966746 processing result tokens.  marker is  fd(DONE)
2003-08-06 08:52:40.966767 inside tds_process_end() more_results = 0,
was_cancelled = 0 
2003-08-06 08:52:40.966789 inside ct_results() process_result_tokens
returned 1 (type 4046) 
2003-08-06 08:52:40.966810 inside ct_res_info()
2003-08-06 08:52:40.966829 ct_res_info(): Number of rows is 0

The function tds_process_end() should process this information and update
the variable tds->rows_affected, which ct_res_info() should then
interrogate. Hmmm...

perhaps you could put a tdsdump message into the tds_process_end() function
(in file src/tds/token.c)

e.g.

  tdsdump_log(TDS_DBG_FUNC, "%L inside tds_process_end() done_count_valid =
%d, done_count = %d \n",
            done_count_valid, tds->rows_affected);

If you put hat just before the returns at the bottom of the function we'll
see if the rows_affected variable is getting updated...

Bill


> -----Original Message-----
> From: Glen Malley [SMTP:glen AT gmo.jp]
> Sent: Wednesday, August 06, 2003 7:42 AM
> To:   FreeTDS Development Group
> Subject:      Re: [freetds] Affected Rows with FreeTDS and DBI
> 
> 
> Hi James, thanks for responding.
> I've attached a TDSDUMP of my test, it's basically just performing an
> update on a single, known entry. I'm by no means clear on the meaning
> of most of the stuff in the dump, but it does seem to say "Number of
> rows" is always 0 at each step in the process.
> 
> I'd appreciate any comments you or anyone else have on this.
> Thanks.
> 
> James K. Lowden wrote:
> 
> > On Tue, 05 Aug 2003 12:42:18 +0900, Glen Malley <glen AT gmo.jp> wrote:
> > 
> >>I'm using the latest versions of FreeTDS, Perl, DBI, etc. to
> >>communicate with MSSQL 7 servers.
> >>My issue is this, after "execute"-ing an UPDATE in a manner to which
> >>I know there will be a non-zero number of rows affected, I am
> >>checking $sth->rows and the $result of the execution, and finding
> >>them to be 0 and 0E0 respectively. I've used trace and not seen
> >>the affected rows value being tossed about anywhere at all, so I can
> >>only assume it's simply nowhere to be found.
> >>I tested this with extremely minimal code, merely doing an update to
> >>all entries in a test table, so I know there should always be affected
> >>rows.
> > 
> > 
> > Glen, 
> > 
> > Welcome to the project.  I think this feature works or can be made to.  
> > 
> > Could we see a TDSDUMP log of your "minimal" test?  There should be
> > indications in there of a call to ct_res_info() with type CS_ROW_COUNT,
> > indicating rows affected.  If the count is -1, it means we think the
> > server marked the "rows affected" field of the TDS_DONE_TOKEN packet as
> > invalid. 
> > 
> > I assume you mean 0.61 of FreeTDS and 1.00 of DBD::Sybase.  
> > 
> > --jkl
>  << File: test-freetds-0.log >>  << File: ATT2214565.txt >>