Sorry that I intervene in your discussion, just a small comment.

> The best would be to pass the changed RecordSet along the event (we
> wouldn't even need to go back to the DB to get what changed), but being
> notified is already a great step ahead.

That thing is not supported by Firebird - it only tells that something was
changed. And I doubt it will be ever supported, since updates in a
transaction can generate tons of changes in the database and will produce
only one event. Please note that strictly speaking only one event is fired
to the each client regardless of the number the event was fired on the
server - in other words you can have event "salary changed" but not "salary
of John Smith changed". Also event is delivered to the client *only if* the
transaction that generated it was committed.

Usually, if people want to know more, they add an "audit trails" table with
an information to application about what was changed - that can be list of
primary keys or a some other custom data structure. This table is filled in
the triggers or procedures that fire the events.

Roman