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

Reply via email to