--- In firebird-support@yahoogroups.com, "zaherdirkey"
<zaherdirkey@p...> wrote:

> i am agree with Alexander V.Nevsky ,

I'm pleased :),

> but "Accounts" Table not changed too match
> i want notify what account changed to listing it in Client List,

Safe in all cases way:

Server side:

Alter Table Accounts Add Transaction_ID Int;

Alter Trigger Accounts_BU
As
begin
[old body]
New.Trans_ID=Current_Transaction;
/*Hypothetical syntax for Post_Event, just idea illustration*/
Post_Event ('Accounts updated',Current_Transaction);
end

Client side, event handler:

Select From Accounts Where Transaction_ID=:Got_From_Event

Using such a strategy you have information:
a) Changes are made
b) Parameter, which is common for _all_ changes and allow to
distinguish them easyly and in time when it is suitable.

If during time slice between Post_Event and Select from client part
of updated records were updated and commited by another transaction -
no problem, you'll get them handling event generated on commit of this
transaction. And you'll get them in desired portions suitable to
process within application, don't freezing it and other applications
based on this server when getting events in case of unexpected
multyple rows update. If you need to handle all changes as a history,
you should maintain internal log of changes, records in which should
be marked by transaction number. It is suitable for such congeneric
applications as asyncronous replicators, daemons-drivers of external
log for rollforward purposes, daemons of remote client cashe refresh,
background event processors and so on. And it allows them to operate
in own tempo, regardless of real tempo of changes accumulation and
don't bothering foregroung operative processes.

> i can build a udf with TCP/IP

Definitily wrong solution. UDF will react on changes in time of
statement execution, not on commit. So, in case of rolling back this
changes, you client application will be misoriented. UDFs or External
Tables can be considered as a part of strategy for multy-purpose
external log maintaining, but only in conjunction with events
parameterized by commited transactions numbers to distinguish really
commited changes from garbage. And this strategy is dangerously
dependent on stability of application which react on this events.
Internal log as buffer for external one or any other processing is
much more reliable.

Best regards, Alexander.