>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.
-
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
