No DB product can give you the number of rows in a result set until the
search has been completed. The Sqlite callback and step approach gives
the application the ability to process the query result as the query
finds each row, avoiding the need for intermediate storage, a most
efficient and robust approach. You should take advantage of it, not
fight it.
Edward Wilson wrote:
What I was trying to say was: with other db products the drivers (or something
somewhere)
calculated the number of rows returned in a query automagicly. I have never
had to do anything
'extra' to get the number of rows in a query other than
resultset-object.rowcout - 'rowcout' being
whatever the syntax was for that particular environment. So what I meant was,
I have always taken
for granted that the rowcount was 'apart of' the query returned from the
database and not
something that I had to do 'extra' in addition to fetching the data to begin
with. I hope this
was clear.
-
ed
--- Puneet Kishor <[EMAIL PROTECTED]> wrote:
On Oct 31, 2005, at 7:54 PM, Edward Wilson wrote:
I simply count the number of elements in my record set
thereby avoiding a double query to the database.
Yes, exactly, I take for granted that the resultset is accumulated at
the database level and not
at the application level.
sorry, I don't quite understand what you imply by the above. Obviously
this discussion stems from the fact that you can't take that for
granted, at least not without paying some cost for it. Because I don't
want to tie up the db doing double queries, I just do it in the
application.
-
ed
--- Puneet Kishor <[EMAIL PROTECTED]> wrote:
On Oct 28, 2005, at 7:20 PM, SRS wrote:
Edward Wilson wrote:
The idea of issuing two selects is, well, a hack, and knowing how
many records one has in a
result-set is a powerful feature
Are you needing a progress bar for the search (ie the query?) Or some
action based on the result set? If the later, get the result set as
your favorite container.. ask the container the size. If its the
first then a "feature" won't help. It still has to 'run' the query
in
order to get the count. It would be like me asking you to tell me
how
many red Skittles are in a package before you open it. As for being a
'hack' .. all your 'feature' would be is a pretty programming
interface around that hack. As I said before, how can the database
know the number of items that will be returned without first
searching
for them.
I think the problem is not so much (at least IMHO) that two queries
have to be performed (that itself is a reasonable expectation), but
that the COUNT(*) query is likely to be slow because of the full table
scan. One option is to use an aftermarket solution... for example, in
my Perl applications once I have queried the db for the columns based
on my criteria, I simply count the number of elements in my record set
thereby avoiding a double query to the database. Although, in reality,
I personally don't mind the COUNT(*) option... none of my databases
are
that large to merit worrying about this.
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs