Hi

> >I am not sure if event can help you. They tell only that
> some event is
> >happened (for example, that some table is changed), but they do not
> >tell which records are changed. In this case you would need
> to re-read
> >complete table.
> >
> Roman, that's silly. A program that what wants notification
> of a stock change doesn't wait on a generic event like "stock
> changed" but something specific like "ibm". Other
> applications may indeed want generic events, but they're
> backed up with log or "to do" tables.

That's what Roman said, isn't it ?

> >If you assume that rollbacks are rare in your system, you
> can write an UDF
> >that will send some information via network sockets and call
> this UDF in
> >each AFTER UPDATE/DELETE trigger. There will be false
> notifications for the
> >changes that are rolled back, but if the rate is low, it
> will not affect
> >your application.
> >
> Roman, Roman, Roman! I am not a complete fool. Events are under
> transaction control and posted to the event manager *after* a
> transaction commits. They can't work any other way,
> actually, since the
> data that reflects the event isn't available to other
> transactions until
> the posting transaction completes.

Roman wasn't talking about events here, was he?

Sorry, usually your postings are very usefull and show that you know, how
firebird/interbase works (no wonder...).
So I assume, you wrote this being very tired or something...

Regards,
Steffen


[Non-text portions of this message have been removed]