> Does this mean that the fetch size is ignored in the default
> auto-commit connection state?

Yes. This is an artifact from pre-JDBC 3.0 implementations. Specifications
1-2 and 2.0 did not say what happens with the statements and their result
sets when the connection runs in autocommit mode. At that time the only
possible way to let the statement keep an open result set even if another
statement is executed over the same connection was to fetch the result set
to the client.

JDBC 3.0 clearly states that if a statement is executed in auto-commit mode,
all previously open statements are closed (and their result sets). This will
be implemented in next release and there will be no more caching of the
result sets on the client (only in TYPE_SCROLL_INSENSITIVE).

Also note that in auto-commit mode the contents on the blobs is also fetched
to the client.

I will add this to the release notes.

> BTW, what is the default fetch size?

As far as I remembed - 400. But you cannot precisely control how many
records will be fetched from the client when isc_dsql_fetch is called.
Server will return as many records as will fit the network packet. So, if
you for example say to the driver that only 1 records should be fetched, but
100 records will fit the network packet, server fill fetch and send 100
records in a single isc_dsql_fetch call (sure, there must be 100 records in
the result set). If you say that fetch size is 101, we will use two
isc_dsql_fetch calls and server will fetch 200 records.

There is only one situation when single record is returned - when you use
positioned updates (SELECT ... FOR UPDATE ...). In this case exactly one
records is returned in one isc_dsql_fetch call.

Roman