> I came up with that idea, too, but there's one fundamental problem I
> couldn't solve:
> How are entries from this event-list removed? I see no way to recognized
> that nobody is interested in this event anymore.

That depends. If your clients refresh their queries (as a reaction to an
event), you only need one event-entry for the tables involved.
Fortunately it's my clientsoftware using my database, so I'm in charge...

On the other hand, if you use events to keep a clientdataset in sync
with tablecontents on the server, you have a point.
I solved this one with a rough and unelegant workaround: My
clientsoftware deletes all timestamped entries of a certain age in this
table right after they connect. So far no problems encountered....

> Additionally, it increases round-trips, because the client has to query the
> server for more information before processing the event.

I think that is always the case. Events by itself say nothing about
record-id's involved. It's the server "shouting to your application that
something has happened. Come and see to find out the details" (well,
unless you specify different events for every row in a fixed-size table...)

On the other hand,

> this does not feel so bad when you look at what you can gain.

Exactly what I thought.

And as a sidenote: I have built usersettings: do you want events or
polling? A user often has no influence on company-firewalls etc, so
their must be an alternative: polling the event-table.


John