Helen Borrie wrote:

> [very big snip]
>
>It's where the transaction in which a statement runs is committed
>automatically. You can't roll it back.
>
>There are two "autocommits". One is "Server Autocommit" (set by the TPB
>attribute isc_tpb_autocommit) which can be used only for executable
>statements (not selects). It's typically used when executing data
>definition statements in scripts. The server takes care of both starting
>and committing such a transaction and, obviously, binds a statement and a
>transaction in a one-to-one arrangement.
>
>Then there is the client-side AutoCommit that was invented by Borland to
>support its implementation of the Delphi data access model. This is the
>one that causes the problems with the TSB. Cosmetically, it has the same
>effect as ServerAutoCommit, i.e. executes and commits a statement in one hit.
>
>However, it uses a "soft commit", a.k.a COMMIT WITH RETAIN, or
>CommitRetaining. It has the extra "bonus" (necessary for Delphi) of being
>available for selects. However, although this "soft commit" does commit
>the work (makes the changes visible to other transactions) it holds the
>database cursors of your SELECT statement open and puts a block on
>post-commit cleanup. So - instead of the TSB being maintained in a smooth,
>roughly FIFO manner, new transactions just keep getting crammed into the
>TSB and never getting cleared out. These long-running read-write
>transactions, that are continually committed with CommitRetaining, cause
>cleanup to get "stuck" at these much lower (= older) transaction IDs.
>
>

I guess you are talking about BDE model rigth? Im using FIB+ and i can
use transaction in the rigth way.
Just to clarify to new users. Using Delphi you can use FB transactions
in the right way with the proper tools.

Best regards.

German Gentile.