> From a non-technical person's point of view I have
> never understood why auto-commit or not affects in any
> way a read operation. It seems to me that since a read
> operation by definition is not changing the database,
> it will never be "commited" anyway.

Consider SELECT * FROM someProcedure that internally does some
inserts/updates/deletes. That's pretty legal, so commit should happen.

There's one issue - it is not possible to tell Firebird to keep cursor open
unless commit retaining is used. Long time ago it was decided that we want
to

a) support multiple open result sets in auto-commit.
b) we do not use commit retaining due to some issues it may cause.

> This is a minor detail perhaps, but it seemed with
> the older InterClient to make more sense that the
> initial query prepared the result set on the server
> and held it there for me to then actually read as many
> registers as I wanted, one by one.

Old InterClient had a server component, we don't. Also old InterClient used
commit retaining, that allowed to keep cursor open.

> In GUI operations with a user sitting in front of
> a workstation the programmer never knows if he is
> going to look at three registers and finish or if he
> actually wants to scroll through all 50,000 records.

Do not use auto-commit mode then. Or let the driver to cache the result set
locally.

> If the users sees what he wants after looking a a
> dozen records then he should not have to take the 2.0
> seconds.

For now you should not use auto-commit. If it is still 2.0, then the reason
must be found. Maybe query execution takes so much. I cannot tell you
without access to the code and to the database. Two years ago for me normal
performance for ~1k object loading was something between 4 and 8
milliseconds.

> Often the users does not know there are 50,000
> records. He sees some of the results and decides he
> needs to redefine his query to be more specific.

Do you know that SELECT count(*) FROM someTable in Firebird means "fetch all
records on the server and count them"?

> One last not on this is that aside from time
> issues, in Jaybird, you also need a lot of RAM on the
> client side to store all the result set when you are
> in auto-commit mode!

As I said before - this will be changed in the next version.

Roman