> Hi, I've a SQL with 4 table joins (one of them is a stored
> procedure), and since I use it for a report, I'm using a IB_Cursor,
> that should be faster and use less resources. But, if I enter the
> SQL in the IB_Cursor editor, click prepare, then open and then click
> last, it takes, for instance, 10 seconds (I can hear IB_Cursor brain
> crunching ;). If I do the same with a IB_Query, clicking on open it
> fills the grid in a snap (at it should, since the result set is only
> of 30 records).
> Am I missing something?

There is nothing innately faster about IB_Cursor - it uses the same
base code. It should normally be much more efficient because it does
not buffer any extra records and does not setup multiple internal
datasets to handle key retrieval separately to record retrieval and so
on.

Often the "efficiency" aspect means that it will also be marginly
quicker, but not necessarily so. For example IB_Query can setup so
that it only retrieves key information for the dataset, retrieving
full records only for those rows specifically referenced. It can
setup so that it does not need to read all records to go to the end of
the dataset etc etc. IB_Cursor does not have these "smarts".

If you want a true comparison perform the tests in code so that you
can force both datasets to visit every record (what IB_Cursor is
really designed for, and what it will do when you hit "last")...

start timer
with IB_Cursor do
begin
First
while not eof then
Next
end;
end timer

start timer
with IB_Query do
begin
First
while not eof then
Next
end;
end timer


Having said all that, I would not have expected the differences to be
noticeable on a selection from 30 records. You may need to run
IB_Monitor to see if you can detected what is happening.


--
Geoff Worboys - TeamIBO
Telesis Computing