Geoff -

I thought that possibly IB Events could be used to monitor the beginning
and end of each session. Then perhaps the number of records being processed
and the type of transaction could be passed as input parameters in a stored
procedure/trigger. This way a 'running count could be maintained based on
the overall transaction row count without interfering with the transaction
itself.

I understand that SQL databases are not designed to maintain record counts.
However in my experience the use of Borland technologies usually comes in
where other products fail to solve problems. As this is not a normal app
requirement, and considering that IB is perhaps the most flexible and
advanced database on the market, I thought this could be an opportunity to
apply some of the flexibility that can only be found in IB to overcome a
common problem.

If I get this figured out I'll post it to the list.

Thanks.

David Keith

>
> Any dynamic tracking of inserted/deleted records will result in
> transaction difficulties - so unless you are willing to serialise the
> insert and delete processing these options are not appropriate.

I understand what you are saying here, but if an app signals the begining
and end of each transaction by registering for an event that is initiated at
the end of a transaction, perhaps this could occur

> As you probably already understand, SQL databases do not support any
> truly efficient "record count" capability. It is alien to the
> concepts behind the client/server and SQL design.
>
> So yes a stored procedure doing a count(*) is probably your most
> efficient option, but it still will not be efficient.

>
> You best bet is to review why you think that; "It is useful to be able
> to review the recordcount whenever I run my app and add/delete data."
> and see whether it is really that useful - and if it is useful perhaps
> it can be retrieved only on specific request.
>