Helens comment
+
I think that you only get one event fired per event type per transaction and
it fires on the commit (someone tell me if I dreamt that).

> As a qualitative comment, post_event is an interaction with a listening
> client. Its potential to add both network and client processing overhead
> is obvious. So, in designing applications that use events, you need to
> balance the benefit against the cost.
>
> For example, IB Objects has the ability to something termed "DML
> Caching". It is possible for each connected client to receive updates
> every time something changes in the database, regardless of which
> application is using it or how many users are connected. It is

implemented

> with events and triggers.
>
> This has obvious benefits in a highly interactive production scenario,
> where the "real-time" requirements have high priority and where updates
> typically happen one-by-one. In a largely batched production environment,
> with few inter-dependencies, it would be a pointless
> waste. (Still...consider how useful it is in a process control
> environment, regardless of the overhead it costs!) Everything between is
> a matter of degree. As a general rule, one choose the tasks for which

such

> a thing would be useful, rather than just blindly implementing it
> everywhere or rejecting it as "everything that uses resources
> non-essentially is out".
>
> Helen
>
> All for Open and Open for All
> Firebird Open SQL Database 7 http://firebirdsql.org 7
> http://users.tpg.com.au/helebor/
> _______________________________________________________
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>