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
