Sorry, my response was far too vague.

What I meant to say was nothing to do with physical limits in the number of
events being listened to...

If you have an event that is posted on say a table update for half a dozen
tables (same event), then you update each of these tables multiple times in
one transaction, then the client gets one event sent to it. The event is
fired at the point the transaction is commited.

Having said that, if I had posted something crystal clear I would never have
found out the 16 per app limit, Cheers Helen. BTW, I haven't used events
hugely in live combat, so again if the above is incorrect, please correct.

JAC

> AFAIK, the limit isn't "per transaction" but that an app can only listen
> for up to 16 named events at once. (I guess your "event types" is my
> "named events"? The trigger or proc call post_event 'Boo' - that is one
> named event...) I never saw evidence of any limit to the number of time
> the event could be posted during the course of a transaction.
>
> For example, in dml-caching, a table could fire triggers that post a dml
> event, as many times as there are row changes committed, all of these
> operations occuring in the same transaction....
>
> The trick is to have the "listening" under control, so that the client is
> actually listening for the events that are going to/likely to occur during
> a particular task. So, with dml caching, for example, an interactive task
> involving two tables will involve a minimum of 6 events (posted from AI,

AU

> and AD triggers on each table), all of which the app wants to listen
> for. No doubt the whole thing could become a riot in the kind of
> application that opens all of the datasets in the entire application at
> startup...but that's entirely the wrong way to do a client/server app,
> n'est-ce pas?