Mariuz2 srtizh:
Это то как раз понятно. Но если один из справочников достаточно большой и достаточно часто обновляется гонять его по сети при каждом обновлении смысл не очень большой. Поэтому я и хочу просмотреть журнал транзакций и при изменении этого справочника на сервере изменять данные в буферизированном справочнике.
а не проще добавить поле со штампом обновления (timestamp) и пополнять справочник по результатам простого запроса (тако же и с удаленными - кидать в табличку - буфер удаленных со штампом времени удаления, по мере отваливания клиентов ее чистить).

Mariuz2 4321:
Спасибо за мысль! Я тоже уже об этом подумал но подумал в поле указывать время последнего обновления. А клиент периодически проверял бы какие обновления после последнего скачивания справочника обновились. Но тогда встает другой вопрос как клиенту получить время с сервера и как заполнять это поле? И все же через журнал транзакций думаю было бы правильнее. Но если никто не подскажет других вариантов, придеться делать так.

1. клиент не должен заполнять поле метки времени. Поле заполняет сервер (триггером на апдейт). Клиент даже может не просить это поле в перечне полей выборки (экономия трафика). Кстати сказать и метка может быть не временем (перевели часы назад???), а попросту свободным счетчиком изрядного размера (int8).

__
ЗЗЫ : Вариант отработки (триггер не описываем):
клиент получает данные:
0. (опционально - от порядка) сдвигает полученное ранее время предыдущей выборки справочника stime0 := stime (если получение времени и данных не оформлять в транзакцию +_ несколько записей в выборке погоды не сделает).
1. клиент получает новую метку времени сервера (в клиентскую переменную) stime
(если время получения данных сдвинуть до времени получения метки времени (пункт 2.) - пункт 0 можно опустить)
2. клиент получает новые данные
SELECT x,xx,xxx from sprxxx WHERE time > stime0;
и удаленные за это время
SELECT x,xx,xxx from sprxxx_del WHERE time > stime0;
ворос только в том, в какую структуру на клиенте дописывать/удалять вновь полученные данные справочников.


в любом случае, если после получения данных о справочнике другой сеанс удалит строку в справочнике, идентификатор которой вы захотели вставить в редактируемую запись - вы получите отлуп (если целостность проверяется) в момент попытки сохранения записи. А блокировать таблицу справочников с момента обновления данных о справочнике на клиенте до момента обновления данных на сервере клиентом - кажется диким излишеством.