> Most applications will have multiple transactions, and certainly
> different apps don't share the same transactions. A transaction
> only "sees" information that has been updated or added that is
> attached to it's own transaction. When something is changed in
> another app or transaction, what is the best way of updating that
> info to other apps or transactions?
>
> I use a transaction refresh to update, but it seems illogical to have
> to have a user continually press a refresh button. I have also played
> around with IB_Event to notify the app of changes to key records.
>
> How does everyone else deal with this? Is there some generic
> procedures that can be used?
>
> Thanks,
> Paul

DML caching is a good and comfortable method for syncronizing,
but there are several nuances:
1) Update notifications are fired on table posts but before update
transaction completion. This can produce some problems with
long time transactions performing more then one update.
2) Table used to register DML events grows up with no limit.
3) There are 2 additional operations accompanying every update:
a) INSERT into DML event registering table on server
b) SELECT from DML event registering table on client

The way I'm using to syncronize several clients is following.

After update transaction completes, client performing update
sends notification over TCP/IP to all other interested clients.
Notifocation contains information about update type
(INSERT, DELETE, UPDATE), updated table identifier and
key information (NOTIFY_KEY_INFO).

Clients interested to reflect updates perform something
like this when update notification hase been received:

on INSERTs & DELETEs
IB_Query.InvalidateSQL;
IB_Query.RefreshKeys;

on UPDATEs
IB_Query.KeyFields.Values['KEY_FILED_NAME']:=NOTIFY_KEY_INFO;
bookmark:=IB_Query.KeyFields.RowData;
IB_QueryJournal.InvalidateBookmark(bookmark);

Regards, vicser