At 09:52 AM 19/03/2004 +0000, you wrote:

>Hi Helen
>
>This worries me . .
>
> > Autocommit true as a rule to abide by, no way. In your design, you have
>to
> > work out which tasks need autocommit and, if you use it, *always*
> > instantiate that transaction. Use autocommit for transactions that
>require
> > it, but wrap its use inside a timed explicit commit cycle.
> >
>I have always exentsively used autocommit and my default transaction is
>that. I only use explict transactions when multiple tasks have to be
>parcelled up.
>
>To change hundreds of small reads and writes to explicit transactions would
>be a massive and messy task

re-read this:
Use autocommit for transactions that
require

> it, but wrap its use inside a timed explicit commit cycle.


>What exactly is the problem?

Autocommit performs commitretaining, not commit. Commitretaining is ideal
where you are doing the same thing, row by row, over and over again,
because it re-uses the resources. But you need to wrap that repeating task
inside a cycle that performs a hard commit often enough to free the
resources used by the transaction, reduce the memory consumption buildup
from halting OIT progress and let the garbage collection facilities do
their job with obsolete record versions.

I was addressing a specific question, not suggesting that others "change
hundreds of small reads and writes". However, it would be wrong advice to
agree that the "classic BDE" approach was right for client/server
applications. To make good use of both multiple transactions AND
commitretaining, choose commitretaining for tasks that benefit from it and
put those tasks inside a well-controlled transaction. In the BDE model,
the default transaction is treated as if it were not there at all.

Helen