Subject Re: [IBO] Locate on tib_query and fetchall
Author stanw1950
I tried all options, but the response time is too slow. I will
research dsssearch mode. I do need the user to scroll through the
dataset (using tib_text components), but no, I don't really want to
cache the entire dataset at the client. Thanks.

--- In IBObjects@y..., Geoff Worboys (TeamIBO) <geoff@t...> wrote:
> > When I open a tib_query and do a locate, a fetchall is done
> > (autofetchall=false). A dialog box appears saying 'fetching query
> > results record ..' while it fetches the 30000 records in the
> > This is slow, to the point of being not acceptable, especially
> > compared to the bde version of the same program. The query (see
> > below) uses partnumber as the order by and then as the locate
> > This field is a unique key in the table (partid is the primary
> > Is there anything I can do to speed up the locate? Am I doing
> > something wrong? I've checked the faqs. Thanks for any help you
> > provide. (Delphi 6, IBO
> The first thing I would be looking at is whether you need such an
> ended query in the first place. Do you really want to cache the
> entire dataset at the client or are you always looking for one
> particular record? If the latter then you should be using a
> rather than a locate.
> Or perhaps you should take a look at some of the sample apps to see
> how dssSearch mode works, since this is likely to solve your problem
> much more elegantly.
> Given that, for some reason, you want the user to be scrolling
> the entire dataset there are a few things you can try...
> * Dont use explicit ordering use orderinglinks.
> * Setup the OrderingLinks so that
> to enable IBOs horizontal refinement.
> * Set FetchWholeRows to false - so that only keys are being
> although this may not matter much given that your records are only
> small.
> * Another possibility is to tell IBO that PARTNUMBER is the
> Since you say it is unique to the dataset this should be acceptable
> and I know that locate has special code to optimise key based
> searches.
> Try the first two options first. If they give adequate response
> are the options I would recommend. If the four fields you are
> retrieving are all very small I would skip the FetchWholeRows
> If nothing else helps try the last option.
> hth
> --
> Geoff Worboys - TeamIBO
> Telesis Computing