Up Prev Next
From: Michael Stather <statherm at home dot com>
Subject: Re: NUMBER of affected rows
Date: May 10 2001 5:39PM
A result set may have a number of rows, a cursor may have a number of rows,
and/or you can specify the number of rows returned in your result set.
If you really wish to pre-determine the number of rows(programmatically) then
send the query as a select statement with a count in it (counting the rows), and
then send the real query...
Although not efficient and depending on how what your environment is like (OLTP
vs DSS) you may not always get the exact same results i.e. you do the initial
select then someone has an update committed prior to your actual query running.
There are other ways around it too, like evil temp tables, or local/client
processing, cursors, batches, transactions... It just gets ugly other than the
There are trade offs every which way you look at it.
J. Michael Stather
Michael Peppler wrote:
> Karsten Spakowski writes:
> > Hi folks,
> > I work with the DBI and DBD Module on a Sybase Server 11.9.
> > After the execution of an select statement, I will check the number of
> > affected row,
> > but I get always the -1.
> Please read the DBI manual, and also the Sybase OpenClient manual.
> There is no way for Sybase to know how many rows a select will return
> without counting them (i.e. without fetching all the rows). So there
> is no way for DBD::Sybase to tell you how many rows a select query
> will return - it can only tell you how many rows *were* returned after
> the query data was completely processed.
> The number of rows affected will only be significant for
> insert/update/delete queries.
> Michael Peppler - Data Migrations Inc. - firstname.lastname@example.org
> http://www.mbay.net/~mpeppler - email@example.com
> International Sybase User Group - http://www.isug.com
> Sybase on Linux mailing list: firstname.lastname@example.org