At 10:53 AM 12-02-02 +0000, you wrote:

>ok, I have understood this, but in my eyes this can't be the problem,
>because with every transaction (every 10 minutes) I write a record in
>a second table for logging (it is the same transaction in which the
>2038 data records are updated), if the transaction would not be
>commited/rollbacked, the record in the logging-table would never
>appear, but I can see ALL records in this logging table - every 10 min
>one record, with timestamp - therefore the transaction must be
>committed correctly.

Not necessarily. If the second transaction doesn't get committed, you can nevertheless still see those records from within *that* uncommitted transaction. The test would be, whether you can see the log records from *another* transaction. Just because a transaction failed to commit does not mean that it somehow rolled back automatically. It remains an unresolved transaction and no garbage collection will occur beyond it in the transaction stack.

How are you intercepting/handling prepare/commit errors?

H/


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org
_______________________________________________________