At 5/18/00 02:29 PM (Thursday), Jim Starkey wrote:

>At 10:58 AM 5/18/00 -0400, Leyne, Sean wrote:
> >Although at first glance events seem to be a useful
> >feature, I have yet to be able to use them, they do not provide a
> >meaningful context in the message. This requires a very time consuming
> >to determine the context, the "cost" of which far outweighs the value of
> >the message.
>
>Could you expand on this a bit? What did you want, how did you
>try to do it, and what didn't work as you expected. I don't mean
>this as a challenge, but to understand whether the existing event
>mechanism is insufficient or just overly obscure.

I'm sure Sean will respond, but I'd also like to so that I can learn how
Jim envisions events being used. Mind you I have not yet used events
because they did not seem to provide enough of a solution for any of my
needs. Here is my generic description of the application developer's
problem which might be solved via use of events:

Let's say I have an application which lists a subset of records from a
table in a visible window. The record set is obtained via a query with a
WHERE clause. That application would like to know when any of those records
are updated in the database so that it can update its window. If any of the
records has been updated, the application would ideally like to re-issue
the same query which populated the window.

To accomplish this, you can code an update trigger of the table to signal
an event such as TABLE_XYZ_UPDATE. When the application receives the event
signal it now knows the table was updated but it does not know if the
update was to one of the records it is currently displaying.

Now the application could just re-issue its query for any such
TABLE_XYZ_UPDATE event. However, it might end up doing a lot of unnecessary
work if updates were all being done to another subset of the table. The
application could also issue a new query to count how many of its current
records have been updated recently (using some additional mechanism such as
a timestamp field in the table).

Both of those strategies involve extra work on the part of the application
which quite likely to be unproductive some of the time.

What I would like to see is the primary key value of the record being
updated sent along with the event ID so that the application would know
immediately if the update was relevant. No additional queries needed. No
network bandwidth wasted. No guessing.