> 1. Indexes: I can use FlameRobin to query RDB$INDICES on both
> systems. The result show that both systems have the same Indexes.
> The RDB&INDEX_INACTIVE is 0 for all indexes on both systems.
>
> 2. So, on my slower system, should I uninstall Firebird classic and
> reinstall as Firebird SuperServer? Note that the SuperServer on the
> fast system is version 2.1, while Classic running on the slower
> system is 2.5. What do you recommend?
>
> 3. Currently both system are accessing the FB database installed on
> the same computer. when my app is ready, the goal is to have the
> app access the FB database on another machine in the network.

Hi Jim!

So far, we don't know the reason for things being slow in your case and would generally recommend trying to find the cause rather than take drastic measures that may result in

a) the problem being fixed
b) the problem returning at a random time

Plans show how Firebird chooses to execute a particular query and different plans may have use very different strategies to reach the same result, so 2 seconds vs 2 hours is possible if using two different plans. The plan is determined from your sql statement and indexes (both of which would typically be identical in your two cases)
and your index statistics. The index statistics can vary with the content of the database, you can have two databases with tables of similar size which will cause very different plans due to the content of your records. Even worse, adding one record to one table can, at least in theory, change the plan, so a program that executes in 2 seconds one day may use 2 hours the next!

The plan is the primary suspect of those that have replied so far (if your indexes are inactive, then the plan will be different). You can find the plan by writing the SQL statement in FlameRobin (or other tool) and prepare the statement. I don't use FlameRobin myself, but typically it involves pressing a button close to a open query/execute statement button that makes PLAN ... pop up somewhere on your screen. Normally, tools would also display the PLAN if you execute your statement.

So, try to find the plans of the slow statement(s) on both your systems and report to this list:

a) the sql statement(s)
b) the plans with the execution time (which query is slow, which is fast)
c) information about which field(s) the used indexes consist of
d) the selectivity of each of the fields in c) (is each value unique or how many duplicates are there generally)

Once you tell us the above, it will be much easier to suggest things that can fix your problem.

Set