At 23:58 9/10/2008, you wrote:

>Thanks Helen.
>
>I guess I really must get my head fully around transactions....the
>subject seems so arcane. Is there a quick concise Guide for "Dummies"?

For developing it's rather a matter of searching around...for example, the TechInfo section at the IBObjects website has a number of papers that address aspects of it; and there are likely articles in the IBO and Firebird FAQ's that will give you that "break-through" that makes you realise the subject is not as arcane as you think.

>I was under the impression that triggers and stored procedures
>automatically run in their own transactions and that they either fully
>complete or give an error and roll back.

No. Triggers and SPs run in the transaction that called them. If the transaction doesn't finish for any reason then the work done by triggers and SPs remains unfinished. The work is committed if the transaction commits and is rolled back if the transaction rolls back.

>Also, if they call other
>stored procedures they all execute as a single transaction under the
>calling procedure?

As above. There is nothing in current release versions that lets SPs or triggers execute independently of the transaction that called them.

>Is the Next Transaction figure indicative of a problem?

It can be...

>Database header page information:
> Flags 0
> Checksum 12345
> Generation 19334
> Page size 16384
> ODS version 11.0
> Oldest transaction 18857
> Oldest active 18858
> Oldest snapshot 18858
> Next transaction 19328
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 0
> Implementation ID 16
> Shadow count 0
> Page buffers 0
> Next header page 0
> Database dialect 3
> Creation date Sep 18, 2008 12:10:41
> Attributes force write
>
> Variable header data:
> Sweep interval: 20000
> *END*

This header looks OK - you don't have any crucial gaps here. No GC has been done for a while (both Oldest Active and Oldest Snapshot are the same and the Oldest [Interesting] is only one less than them. There is possibly garbage around for some of the 469 more recent transactions, which wouldn't slow down the database as you describe.

This looks perfectly reasonable for a database that is three weeks old. Is it slow and/or crashing at the moment? How many users were logged in when you took these stats? What were they doing?

You don't get garbage from all transactions: only from those that do updates and deletes. The trap is that *any* long-running transaction will keep old record versions "interesting" and the garbage collector won't touch them. (The one exception: a Read-only transaction in ReadCommitted isolation does not cause the OIT to get stuck.)

Are you using Delphi applications?

./heLen