After a few hours of research I found a performance bottleneck in my application caused by
a bad index: The primary key (with data type "char") of an often used table was
accidentally defined as "Case-INsensitive", so most of the queries with joins to this
table were un-optimized and slow. I detected this problem with the query plan tool from
dbsys.exe and changed the index to "case-sensitive". Because this table is involved in
many master/detail- and lookup-relationships of the TDBSAMTables in the application, the
whole application now performance much better.

But beware: If detected the problem while optimizing a single SQL statement of a rarely
used part of the application. It was a very nice side effect that changing this index is
good for the whole application.

Optimizing a single SQL query is easy with dbsys, but what about TDBISAMTables? Is there
any chance to detect un-optimized data access even if SQL is not used? Is it possible to
"ring the bell" if a needed index is not found? That would be very helpful for optimizing
a slow application based on TDBISAMTables...

Georg,

<< Optimizing a single SQL query is easy with dbsys, but what about
TDBISAMTables? Is there any chance to detect un-optimized data access even
if SQL is not used? Is it possible to "ring the bell" if a needed index is
not found? That would be very helpful for optimizing
a slow application based on TDBISAMTables... >>

Not in DBISAM 4.x, but in our upcoming ElevateDB product, we are making
improvements in this area, specifically with respect to Locates and Filters.
The filters now can show their plans like queries, and Locates can indicate
whether they used an index or not.

--
Tim Young
Elevate Software
www.elevatesoft.com