> meus latin est non valde bonus :)

Quidquid latine dictum sit altum videtur.
(IIRC)


Having a lot of indexes will have a cost. If you insert 300.000
records it might be worthwhile to investigate whether de-activating
indexes during the insert prosess will improve the situation. On the
other hand, deactived indexes might not be acceptable for other uses
during this. I assume you have considered whether all indexes need
to be present.

The "Depth: 4" indicates that increasing the page size of the
database might be a good thing.


<<
Index TRANSAC_SEARCH_101_IDX (3)
Depth: 3, leaf buckets: 5703, nodes: 5150351
Average data length: 0.00, total dup: 5150293, max dup: 2779803
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 5702

>>

A max dup of 2.779.803 could be a source of trouble with older
Firebird versions with updates/deletes (and maybe not very efficient
at selects). Maybe it's all right in your situation. The "trouble"
would be slowness, not corruption, though. This could usually be
fixed by including the primary key (or a unique field) in the index.
Is there a primary key or a unique constraint for in TRANSAC_SEARCH_RES_FS_A_2?


--
Aage J.