skander_sp wrote:

> Im using IBO components in a new aplication,
> the SELECT it's a "not simple" query , he take 150 fields
> from about twenty Joins.

It can be worth taking a look at the surrounding code, make
sure you have nothing that is doing repeated field look-up
by name and that sort of thing.

For example I have a stored procedure returning some 300 fields
and yes it takes some considerable time to prepare (it is
very complex internally). For a long time the procedure seemed
to run very slowly indeed and I realised the CPU use was mostly
on the client side - it turned out to be some code in the
report processing that was dragging it down, looking up fields
by name. Name search will get quite slow as the number of
fields grows. I fixed that and a procedure that used to take
20 minutes to run now takes less than 1 minute.

Depending on how you are going to use the data you may well be
advised to use TIB_Cursor instead of TIB_Query, there are less
overheads... especially when, with TIB_Query, you are trying to
set-up buffering for full rows of 150 fields. (Note that
TIB_Query, depending on its configuration, may be preparing
multiple queries not just the one.)

... and this of course begs the question of exactly how you are
doing the time comparison. If you simply prepare the TIB_Query
while it is not attached to anything it should - I hope - be
quite fast. As soon as you attach it to things like a TIB_Grid
you will be forcing various initialisations that do indeed to
name lookups etc that will make the overall time appear slower.

The other thing that can impact time comparisons when using IBO
is that the first prepares you do after a connect will be
impacted by the other background work IBO does to retrieve
other metadata that it uses (such things as primary keys etc).
These are overheads not experienced in more limited situations.

Like so much with computers it can be difficult to make good
comparisons... and do tie down exactly where overheads are
being experienced. In IBO...

1. Create your TIB_Query (or TIB_Cursor)
2. Run the application, connect and prepare your query
then unprepare your query (this ensures that IBO's
internal metadata is primed... and so, for that matter,
is Firebird's cache).
3. Now do several prepare/unprepare cycles and get an
average of the times.

Now try attaching whatever controls it is you wanted on the
query and do the same thing again - this will give you a better
idea of where you are hitting the overhead and so offer you a
better chance of being able to improve on the situation.


The other thing very important thing to remember is to use
IBO's SQL monitor. Start it up and see what IBO is actually
sending to the server, this often helpful in explaining why
some things are taking longer than you may expect.

--
Geoff Worboys
Telesis Computing