At 04:02 PM 19-04-02 +0100, Jason Chapman wrote:

>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).

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?

-- H

All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________