Hello Helen,

the problem is not the data written into database during the
transaction, this works all fine! Data is updated and inserted into
the database with a perl script. All written/updated data can
perfectly be seen when I connect to the database from another windows
client using ibconsole. therefore, in my opinion, the transaction in
the perl-script must be committed correctly.

for intercepting/handling prepare/commit errors i do nothing special,
the script terminates on failure. But until now an error has NEVER
appeared, all data and all log-data is correctly in the database! No
records are lost!

But the db-file-size is growing too quickly even if there are ONLY a
lot of updates in the transaction.

--- In ib-support@y..., Helen Borrie <helebor@d...> wrote:
> At 10:53 AM 12-02-02 +0000, you wrote:
>
> 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
> _______________________________________________________