> itself. POST_EVENT obviously isn't a lot of use if you make up
> its string
> on the fly. The idea of events is for client apps to *know* what
> the event
> identifiers are and to listen for them. Your attempt to "enhance" the
> event by adding run-time data to it should be trapped somehow (but
> apparently isn't), even if it is just swallowed.
>

This is off on a tangent but I disagree. I am doing something similar. I
have a trigger which "calculates" the event name based on a base string and
then a value (the key field value), very similar to this. When I show a
screen for example that allows the customer master record to be edited when
the "OK"/"Save" button is clicked, and the screen is first opened I register
an event alerter for the record I am editing. This allows me before the
current user saves the record, to alert the operator to the fact that
someone else has changed the record. This gives the operator the choice to
exit or continue. While this scenario is unlikely to happen many times in a
day, it allows me to handle a scenario that can happen, without resorting to
a pessimistic locking scheme (which is how when this application (Delphi
app) was based in paradox used to work - the record was placed in edit mode
when the screen shown in the onFormShow event handler).

Regards,
Kevin.