Ann,

Thanks for your thoughts.

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.

I appreciate your suggestions.

Jim

--- In firebird-support@yahoogroups.com, "Ann W. Harrison" <aharrison@...> wrote:
>
> On 1/21/2011 2:40 PM, drjimwalsh1 wrote:
> >
> > On machine A, the time from when I launch the app until the time that the results appear in the 3 grids is around 2 seconds, almost instantaneous.
> > Firebird server: version 2.1 (fbserver.exe version 2.1.3.18185)
> > Firebird ODBC driver: version 2.00.00.148
> >
> > On machine B, the time to complete that same task takes over 2 hours.
> > Firebird server: version 2.5 (fb_inet_server.exe ver 2.5.0.26074)
> > Firebird ODBC driver: version 2.00.00.150
> >
>
> First, you're running two different types of Firebird on the two
> systems.
>
> fbserver.exe is the "superserver" which handles multiple connections
> that share a cache. By default that cache is quite large
>
> fb_inet_server.exe is the "classic" version in which each connection
> is a separate process. When running locally, the connection is made
> by the actual client process. When handling remote connections, each
> new connection starts a copy of fb_inet_server on the system with the
> database. The fb_inet_servers don't share caches. So at the very
> least, that system is running in a tcp/ip local loopback, and each
> connection has a small cache.
>
>
> Second, even that doesn't explain the difference between ~2 seconds and
> ~2 hours. It's possible that the slow system is missing some (all?)
> indexes or that the indexes are inactive. Query RDB$INDICES to see
> if the expected indexes are present and activated.
>
> Good luck,
>
> Ann
>
> By the way, classic can be a very good solution in some cases,
> especially on a multi-processor system. The superserver is
> multi-threaded but runs only one thread at a time to avoid
> interlocking data structures ... well also because it was
> designed at a time when multi-processors were out of favor.
>