Hi Geoff !

GW> Have you checked the plans issued when you prepare the statement? (To
GW> be sure none of the joins are using natural).

Yes :

PLAN SORT (JOIN (JOIN (JOIN (JOIN (JOIN (E NATURAL,A INDEX
(RDB$PRIMARY20)),P INDEX (RDB$PRIMARY19)),RH INDEX (RDB$PRIMARY10)),I INDEX
(RDB$PRIMARY4)),EX INDEX (EXEMPLAR_IDX_VOL_FASC)))

I can't see any way to optimize it more than that.

GW> The SchemaCache will only help on 2nd and subsequent connnects, did
GW> you check this? In fact, even without SchemaCacheDir you should
GW> normally find that the second time you open the form (in the same
GW> application session) that it significantly faster **IF** the problem
GW> is related to initialisation of schema cache details. If this is not
GW> the case, then we can ignore the SchemaCache as the cause of the
GW> problem.

Yes, the second time I open the form it is much faster than the first time.
I though that with SchemaCache it would be fastest in the first time too.
Anyway, Jason told me that schemacache only makes a diference in very low
speed networks.

GW> I find Interbase is often quite slow for the first few requests after
GW> starting up. Are you sure your server is not dying (check the
GW> interbase.log).

Server is OK.

GW> The IB_Profiler dialog may help show where the problem is - I've not
GW> had much experience with it myself, but it does give some interesting
GW> details that may help.

I'll give it a try :)

GW> If the delay re-occurs after a few seconds as you describe, I am
GW> wondering if it is due to IBOs background work in retrieving
GW> additional records. You can check this by disabling the OAT
GW> management for the transaction (set Transaction.TimeoutProps.Attempt
GW> := 0).

Thanks for the answer Geoff !

[]s

Carlos
WarmBoot Informatica - http://www.warmboot.com.br
Interbase-BR - http://www.interbase-br.com