Re: How to get total number of rows before executing the SQL /fetch

From: Edward S. Ferrara <eferrara_at_bellatlantic.net>
Date: 1997/10/07
Message-ID: <01bcd2cf$e9ccaf20$ce509fcf_at_eferrara>#1/1


I was wondering if you could not create a procedural block that collected lets say the first 100 to 500 row and then fetch the next etc. This way you can malloc the space you need without having to have two different queries cached parsed etc. (The one with count(*) and the one without.)

I have seen this technique done in Visual Basic and a few other languages. We used to do it in the 4GL days as well.

> > > We want to know the toal number of rows expected in a cursor fetch
> > > before doing actual fetch. (before executing)
> > > thanks
> > > Sidhartha
> > Computers are not clairvoyant. The best shot you have isto duplicate
> > the query with "COUNT(*)".
> I would be cautious with useing the count(*), as the query is not
> exactly like the one you are attempting to do the query will not be
> cached already and will need to be reparsed when the second query runs.
> Also, if you are trying to determine, by the number of rows returned
> that the query may be long-running due to possible amount of rows
> returned, you will be defeating your purpose (as you will have done that
> long-running query to determine the number of rows that will be returned
> so the user can decide if they really want to do that long running
> query... kinda a catch 22)...
>
Received on Tue Oct 07 1997 - 00:00:00 CEST

Original text of this message