At 07:13 PM 15/06/2005, you wrote:

>I have read that "read commited" should not be used, because it
>is "broken".

In what way is it broken?

>I have read that I should use "snapshot".
>
>If using snapshot is the correct choice (for possible queries that my
>sit on a users display for hours),

Snapshot is no better for queries that sit on a user's display for
hours. That kind of query should be a read-only query in read committed
isolation.

>then what would be the correct
>settings to use for this transaction type when using the following:
>
> 1. Firebird API
> 2. ODBC
> 3. OLEDB
>
>I think this information written in a clear manner could help a lot of
>people from getting "stuck" transactions.

It depends what you mean by "stuck" transactions. Are you confusing Read
Committed (a transaction isolation) with CommitRetaining, a form of COMMIT
that causes cursors for result sets to be retained after the commit?

The Firebird API, ODBC and OLEDB are not a paradigm. An ODBC driver and
and OLEDB driver would each provide a specific implementation of the
Firebird API, which might or might not support CommitRetaining but would
both support all three of Firebird's transaction isolations.

Result sets held for long periods should be in Read Committed isolation and
in Read Only mode. Long-running read-write transactions all have the
potential to get "stuck", from the POV of garbage
collections. Long-running read-only *snapshot* transactions will also
cause this since, unlike Read Committed, snapshot transactions have to
provide a repeatable read.

./hb