At 07:43 AM 8/03/2005 +0100, you wrote:

>Helen,
>
> >>I have a tdatabase with transisolation set to tiReadCommitted. Do I
> >>need to do periodic hard commits or are those done immediately?
>
>H> Oh dear, you are using the BDE. This is the source of your problem,
>H> unfortunately.
>
>He didn't even tell what the problem is and you have identified
>the source already! :-)

Um, Nando, where have you been? This guy has been posting about increasing
memory usage that doesn't get cured except by shutting down the server. It
would have been easier *for you* if he had kept it in the same thread, though.

>H> If you don't start and commit the transaction explicitly,
>H> the BDE driver uses CommitRetaining to simulate the non-transactional
>H> behaviour of the Paradox engine and memory resources get stuck forever,
>H> until the database is in a shut down state.
>
>AFAIR the BDE doesn't even know what commit retaining is unless you set
>special driver flags.

Uh-oh, Nando, Commit Retaining was *invented* for the BDE. The InterBase
drivers default to it unless you use Database1.StartTransaction and
Database1.Commit.

>What it does is auto-commit each statement, so
>the OP is safe: it might not be efficient, but it's not going to
>generate garbage or other unpleasant results.

By default, it autocommits each statement and uses CommitRetaining. This
kind of autocommit is client-driven: it is Post followed by
CommitRetaining. This is *different* to setting Server Autocommit in the
BDE driver flags, which causes the isc_tpb_autocommit flag to be set in
every TPB.

>And, the Paradox engine does support transactions. :-)

No, the Paradox engine does not support transactions. *Delphi* provides a
logical transaction that it wraps around dataset caching. I think you do
know the difference between the logical transaction context and the
physical transaction. The Paradox engine has *never* supported
transactions. For multi-user concurrency, it relies on the abominable
paradox.lck file that is maintained by the BDE for all applications that
access the database files and can blow up whenever a draught passes through.

>H> That's one of the many reasons there are so many abstraction layers
>H> available for IB and Firebird: the BDE "out-of-the-box" simply *never*
>H> manages transactions properly.
>
> >From this POV it's not much worse than dbX or any other layer that
>don't support parallel transactions (which include ODBC and JDBC, for
>the record). Let's say it's much easy to get it wrong due to the
>default autocommit behaviour.

Let's say an understanding of how the BDE does autocommit makes it easy for
Delphi applications that were written for Paradox or Access, using the BDE,
to come to grief on transaction management when the DB engine is simply
swapped over to IB or Firebird (as is the case here).

ODBC, JDBC, et al., which don't support parallel transactions, DO use
isc_tpb_autocommit for their autocommit option, not the client-side
autocommit that is implemented by Delphi + BDE. I haven't seen any
evidence that the InterBase driver for DBX does anything better than ODBC
or JDBC, but I believe it does implement ServerAutoCommit.

>I share you opinion that, anyway, the sooner the OP leaves BDE to its
>fate, the better. :-)

The BDE became a dead end for IB/Firebird after IB 5.6. It never was a hot
option for transactional databases, since it purposely hid parallel
transactions from the developer. Neither, because of those infernal lock
files, was it ever a hot option for multi-client setups.

./heLen