At 07:29 PM 29/02/2004 +0200, you wrote:

>At Sunday, February 29, 2004 5:19 PM Kevin Herrmann Wrote:
> > Yossi, unsure of the length limitations on POST_EVENT

An event alert is only supposed to be a name, not a message. The limit is
15 characters - not even long enough to accommodate the name of a table if
the full 31 characters are used.

>but couldn't you
>just
> > concatenate the messages with a separator? Seems like the first part will
>be
> > defined by you and will be a limited set of values. Then add the latter
>part.
> > So, use an integer or short string, a separator, and then the table+record
>ID.
> >
> > Some examples:
> > POST_EVENT 'TableUpdate' || '/' || 'Customers-12345'
> > POST_EVENT 'TU' || ':' || 'Customers-12345'
> > POST_EVENT '3' || '-' || 'Customers-12345'
> >
> > Then parse event text in app.
> >
> > Kevin
>
>Hi.
>
>How can I do it, The event name is unknown How can the client register this
>kind of event ?

The idea is that the client register interest in events whose names are
known. So the DBA who writes the PSQL module documents the names of the
events and the software developer sets up an alerter to listen for specific
events. Events aren't designed to pass "informative messages". The client
receiving a certain event responds to it.

IB Objects implements a feature called DMLCaching, which maintains a table
of I/U/D data events that includes the table name(s), their keys and the
operation that was performed. Clients receive custom event messages
(through a scopable messaging system built in to the client interface) as a
result of triggers in this DML Cache table.

Assuming you aren't planning to switch to IBO just to take advantage of
DMLCaching, there are still things you can do with the event mechanism to
make it do what you want.

Events are cached in FIFO order and are not delivered until after the work
is committed (and, if it rolls back, they are never delivered). You can
use a single event alerter in your client to to group up to 15 related
events. Just devise some event-naming system that you can tie up to your
event alerter's handlers so that the event alerter itself knows how to
respond to each one.

<preaching to the choir>
My big caveat with events for global notification is "noise". Do I really
want to stack up piles of events for every DML operation? If your client
app is set up with the appropriate isolation and lock resolution settings,
then it isn't normally going to be interested in others' DML events. If it
actually happens upon a row whose current committed state is different to
the application's own assumptions, normal transaction characteristics will
take care of it in whatever way you choose. ReadCommitted isolation with
WAIT will take care of most needs; an efficient visual refreshing system
on the client will reduce the chances that the user will bump into conflicts.

I'm not saying "never use events", any more than I'd say "never drink
beer". But there is a healthy level usage for both that varies according
to conditions. It's neither healthy nor necessary to satisfy all your
daily fluid intake requirements with beer. There's nothing quite like a
cold beer when you are hot and thirsty but it's not a healthy substitute
for drinking-water. At least in your applications, if the drinking-water is
bad you can do something about it.

In your app, if you need an event alerter, create one when you *actually*
need it (or activate an already-created one). Serve the beer when the
conditions demand it. :-)

</preaching to the choir>

/heLen