iBase.ru Forum

Допустим необходимо оперативно уведомлять клиента об изменениях
данных.
В существующей реализации можно узнать лишь о том что что-то изменилось и приходится перечитывать всю таблицу.

Хотя на серверной стороне можно указать конкретно какая запись изменилась напр .
POST_EVENT 'CHANGE_TABLE_REC'||'#'||CAST(NEW.PK_FIELD as varchar(32));

Вот если бы сервер отсылал бы уведомления всем клиентам которые ждут событий с именем starting_with('CHANGE_TABLE_REC#') то стало бы возможным перечитать только изменившиеся записи
преобразовав в число то что следует за символом разделителем.

соответственно в fbclient должна быть функция типа isc_wait_all_eventS

dostap писал(а):Допустим необходимо оперативно уведомлять клиента об изменениях
данных.
В существующей реализации можно узнать лишь о том что что-то изменилось

Да

dostap писал(а):приходится перечитывать всю таблицу.

Нет

Думай ещё

Ничё в голову не приходит.
В каком направлении думать толканите пожалуйста.
Общение с сервером на основании собственных классов

[quote="dostap"][/quote]
Что ты должен получить, если изменилось сразу с десяток записей?

Поищи здесь тему про диспетчера такси, там обсуждали некоторые аспекты использования евентов.

Если консерватория правильная, и действительно есть необходимость получать изменения таким образом, я бы отдельную таблицу вёл, куда триггерами заносил все изменения, и посылал уведомление "что-то изменилось". А уже на клиенте лезть туда и выгребать изменения.
Либо даже в самой таблице вести timestamp изменения, и индексно выбирать более свежие запомненного штампа. Только в этом случае удалённые не отследишь.

Спасибо. Мысль насчёт отдельной таблицы даже не приходила в голову.

Ну по-разному можно... Можно и по тем же евентам на добавление/изменение данных, но это не совсем правильно, потому что когда будут работать двадцать-тридцать человек, эвенты будут сыпаться непрерывно, и клиентское приложение "умрёт" так как будет занято только их обработкой.
У меня ситуация такая, что само течение времени является значащим событием, то есть по истечении определённого времени нужно помечать конкретные данные как "устаревшие" и отображать это на клиенте. Поэтому сделал механизм на эвентах, но с контролем по времени. То есть есть еще периодически срабатывающий таймер, который "подбирает" то, что не обработалось в EventAlerter А алертер, в свою очередь обрабатывает поступившие сообщения, после чего делает "задержку" Если в этот момент поступают новые сообщения, алертер выставляет флаг "были необработанные сообщения", и сработавший таймер выполняет их обработку. Если же новых сообщений не было, сработавший таймер ничего не делает. Примерно так. Малость сумбурно, но в целом идея, думаю понятна...

[quote="Kotъ-Begemotъ"][/quote]
Ты зарываешься в детали реализации "как уведомить клиента о том, что что-то изменилось".
А автору, как я понял, нужно "как получить только то, что изменилось". Чувствуешь разницу?

WildSery писал(а):

Kotъ-Begemotъ писал(а):

Ты зарываешься в детали реализации "как уведомить клиента о том, что что-то изменилось".
А автору, как я понял, нужно "как получить только то, что изменилось". Чувствуешь разницу?

Да я как один из возможных вариантов привёл... А СуперПуперУниверсальных решений давно не ищу. Это всегда занимает неоптимальное время, и всё равно полностью универсально не получается...