Lester,
I think open transactions are the reason for the OAT (Oldest Active
Transaction) not to advance, and it is certainly possible for a transaction
to be active after closing queries. I know nothing about events, but they
have no Transaction property, so I would be surprised if they could stop
the OAT from advancing.

If your transaction is only connected to one connection, I guess it could
rollback when the connection is closed, explaining that your OAT advances.

BTW: Starting transactions is normally not neccessary - IBO starts whenever
required. Just concentrate on commit/rollback.

Hope you'll find an open transaction,
Set

At 08:13 31.01.2001 +0000, you wrote:

>Svein
>
>I did not mention it, because I thought that closing the table (
>xx_query/xx_cursor ) did close the transaction. Is this possibly where I
>am going wrong?
>
>Certainly when I close the connection, everthing is 'disconnected', but
>events need the connection open. Where I am actually copying
>information, there is a Start/Commit, but is it possible for a
>transaction to be active if all the table type links are closed?
>I do not rely on default transaction, so only my 'real' ones should
>exist.
>
>Svein Erling Tysvær wrote:
>>
>> Lester,
>> closing tables/queries doesn't allow for the OAT to advance, but committing
>> (using Commit, not CommitRetaining) transactions does. You probably do this
>> already, but I thought I should mention it since your mail didn't mention
>> transactions at all.
>>
>> Set
>>
>> At 07:23 31.01.2001 +0000, you wrote:
>> >The only thing that I would add is although events are nice, I still
>> >have 'growth' if I leave their connection permanently open. I have to
>> >drop and remake every hour to ensure that OAT can roll on preperly. This
>> >may be me, but MOST of the time, all tables and other components have
>> >been closed and are not opened until the event announcing a change is
>> >recieved, which can be several hours at a time.
>
>
>
>
>