> 1) For a "select" statement it seems that commit
> and rollback don't have any relevance since a select
> statement does not change the database in any way.
> Have I missed something here?

Yes. If transaction isolation level is not read committed, JayBird has
to commit after each statement in order to see changes made by other
transactions. Also there's a concept of selectable stored procedure,
which can do inserts, updates and deletes even somebody executed
SELECT statement.

> Likewise there should be no difference between
> doing a select with autocommit true or false.

Behavior of the driver in auto-commit is described in JDBC specification.

> 3) One of the advantages of a client / server
> setup is that the client does not have to read all of
> the data which reduces the traffic on the network.
> True here you requested the select data, but how often
> does the user then decide he does not need all of that
> data.

Auto-commit mode is not the best one for client-server setup.
According to the specification, result set will be automatically
closed if you execute any other statement over the same connection. In
non-autocommit mode everyting is ok.

> 4) Interbase is a lot better at holding all of
> this data than Java is. Jaybird being in Java, shares
> (or takes away) the same memory the Java program is
> using.

As I said, current implementation is not the best one. Volunteers welcome.

> We have adjusted our program to do all selects
> with autocommit = false. Is it important to commit
> before closing the statements?

No, you can close statement and then commit. Also switching
auto-commit mode will cause implicit commit.

> Or will closing the
> statements free all the resources in Jaybird and
> Interbase?

It will.

Roman