>> I am not sure what you mean by "can be rolled back and the engine wasn't
>> able to undo stuff" - how could that possibly happen? I was under the
>> impression that if I roll back a transaction, all of its changes return
>> to the state at the beginning of that transaction. Do you really mean
>> that a rollback might fail??
>
> No. A rollback reverts back. Period.
>
> What I meant is, that basically a commit is better for transaction
> statistics, so what the engine tries with a rollback is to undo stuff
> and then calls commit. The engine isn't able to do that e.g. when
> working on a larger number of records, e.g. by deleteing records and
> then calling rollback.

That might be exactly what happened, actually: There is a part of my
program which involves deletes AND at the same time can cause the server
to fail due to insufficient memory (on a 32bit system).

>> That is quite possible. While I try to properly close all transactions,
>> there are simply too many places where they occur (and too many
>> connections to the same database file, using different access objects)
>> to be sure that I caught them all.
>
> By "close all transaction" I get the impression that you are starting a
> client transaction explicitely?

Yes. And I have a "rollback on quit" in all my applications.

> Also, watch out AutoCommit transactions, which basically do a commit
> retaining behind the scene when commiting. Although a commit retain
> makes changes to concurrent connections/transactions visible, the
> transaction is still active in sense of the oldest active transaction,
> thus this value can't move forward.

I don't use autocommit, but I may be using commit retaining. Will check.

Thanks,

Pepak