Вот, понадобилось тоже заняться этой ерундой интересной темой. Собственно, вполне подойдет, думаю, способ с пометкой записей timestamp или счетчиком обновления таблицы и последующей выборкой на клиента записей, измененных с момента последней выборки. А что касается опасности пропуска записей, между получением метки и завершением транзакции которых клиент успеет произвести выборку - то не так это и страшно.
Назад в будущееВремя... У меня сколько угодно времени! У меня машина времени!
Можно брать записи не с момента последней выборки, а чуть раньше. Ну да, записи будут рефрешиться повторно, но ведь это
Amris MirddinФигня по сравнению с мировой революцией.
Конечно, если сидят сотни машинисток, то это уже будет серьезной проблемой, но ведь в реальности это редкость.
А если теоретически. Неужели нельзя отследить момент пропуска записей? Теоретически количество событий (а ведь мы его знаем, не так ли?) должно быть не больше, чем количество обновленных записей при очередной выборке (на каждое закомиченное обновление получаем одно событие). Если вести лог изменений в отдельной таблице, то достаточно подсчитывать количество событий и количество выбранных из лога записей. А если не вести лог, а ограничиться метками в основной таблице? Тогда можно завести поле "версия" и в after update делать NEW.Версия = OLD.Версия + 1 . Тогда при выборке where Update_ID > :LastUpdateID суммировать разницы версий (между полученной из базы и локальной - полученной ранее) для всех обновленных записей и сравнивать с количеством полученных событий.
Ну а если обнаружили "недосдачу", то откатываться назад до тех пор, пока количество событий и количество обновленных записей как минимум не сравняются.

Трава хороша, но одному курить скучно.

Под окатом назад можно теоретически понимать, например, повтор выборки с постепенным уменьшением LastUpdateID (если установить сразу в 0, то будет FullRefresh, так?).
Да, речь идет о случае отсутствия удалений (или предположении, что отслеживание удалений нас не интересует).

Карабас Барабас Sextonспособ с пометкой записей timestamp или счетчиком обновления таблицыесли ты используешь счетчик обновлений, то пропуска быть не должно, если я все правильно понимаю
Неправильно, ибо тынц.

Sextonв after update делать NEW.Версия = OLD.Версия + 1
Ой, after update, конечно, заменить на before update, а в before insert делать NEW.Версия = 1
Карабас Барабасдак ты храни на клиенте последнее значение счетчика, зачем из генератора брать ? или я чего-то не догоняю ?

Еще раз тынц внимательнее. Зачем там сравнене с генератором (то есть, хуже то не будет, но зачем?), я и сам не понял. Там суть не в этом. Ну и

Карабас БарабасА ты зачем полугодовалый топик поднял ?
Возникла необходимость сделать автообновление данных при многопользовательской работе. Столкнулся с проблемами реализации. Стал искать топики на эту тему, чтобы найти ответы, а нашел описание тех же самых проблем.
Так как тема далеко не новая, то поднял старый топик, чтобы новый не плодить.

SextonТеоретически количество событий (а ведь мы его знаем, не так ли?) должно быть не больше, чем количество обновленных записей при очередной выборке (на каждое закомиченное обновление получаем одно событие).
Уточнение. Общее количество полученных событий должно быть не больше, чем общее количество обновленных записей.

Карабас Барабас SextonВозникла необходимость сделать автообновление данных при многопользовательской работеКак один из вариантов - способ, описанный мною же, тут же, там и удаленные записи отслеживаются

/topic/187250&pg=-1#1586487

Так и я пришел к такому же способу в конце концов (только мне больше понравился вариант с timestamp, так как timestamp у меня все равно используется). И в реализации прост, учитывая, что формы у меня генерятся автоматом. Гонял возможные варианты работы этого метода и понял, что теоретически может быть пропуск данных. Думал, умные люди знают, как сделать правильно. А умные люди пишут о той же самой проблеме. Стал думать дальше и пришел в голову способ, который сюда и запостил: может кто подскажет, где в нем ошибка.
Карабас БарабасДа нафига вобще обновление делать по событию ? Чтобы все моргало непрерывно ? Даже если ты ограничишь обновления по минимальному промежутку между ними, все равно это неудобно. Мое ИМХО состоит в том, что только пользователь должен решать, когда ему надо увидеть обновленные данные.

А с чего будет моргать? Как правило, в событии обновляется всего несколько записей (а в большинстве случаев одна). Разумеется, запоминаю состояние курсора и отключаю обновление Data-Aware компонентов, а потом все это восстанавливаю. Разумеется, если DataSet не в dsBrowse, данные кладутся в буфер и выбираются из него, как только DataSet переходит в этот режим.

Карабас Барабасможет быть, я не прав, может быть ты права ... (С) Бутусов

Да не так это и важно. Идеальных решений все равно нет.
Я просто выложил способ, так как не могу обнаружить в нем проколов. Вдруг кто-то другой сможет. Может, предположние, что всегда известно количество посланных из базы событий не верно, может еще чего...

Лентяй
Вот интересно, как народ поступает с добавленными записями. На клиенте висит набор данных уфильтрованный и засортированный ползателем насмерть. И тут приходит event, по поводу того, что запись с id таким-то добавили. И чего делать?
TpFIBDataSet.CacheAppend(id, true)

Лентяй
И чего, FibDataSet при этом распарсит Sql-оператор в SelectSql проверит, попадает ли добавляемая запись под where кляузу и решит, нано ли вставлять этот id в локальные буфера DataSet? Если да, снимаю шляпу.
Fib просто вставит запись в локальный буфер, а потом сделает для нее Refresh.
А по теме вопроса, есть ли просчеты в предложенном способе так никто ничего...

Amris MirddinДа нет проблем.
Но платно

Да меня бы устроила даже инфракрасная коагуляция анальной трещины: да, нет. Ну а потом можно и комментарии добавить. Вопрос ведь не практический, а так - спортивный.

ЛентяйА вот еще интересная ситуация (вариаций много придумать можно). Имеем SelectSQL такого скажем вида:
Сосед добавляет/изменяет/удаляет записи в Spr - чего делать? Писать на каждый Select свой обработчик прихоящих Event?

Один обработчик вешается сразу на события от всех таблиц, входящих в запрос (на Фибах получить список таблиц элементарно). В обновляющем запросе используется тот же select, что и в основном, с наложением дополнительного условия Datastamp >= :LastDataStamp (ну или кому что нравится). Дата (или счетчик - опять же, кому что нравится) обновления записи берется максимальная между t.Дата и s.Дата. Версия записи определяется суммированием t.Версия+s.Версия. Далее все сводится к случаю с одной таблицей.
Но с одним условием: в составном select'е должны учавствовать только таблицы, связанные 1:1, причем выбираться должны все записи. Иначе, нарушится связь между количеством событий и количеством выбранных версий. То есть, в общем случае метод с версиями не подходит и отследить пропуск записей при обновлении невозможно, что и требовалось доказать. Доказано Лентяем
Получается, что обновление действительно проще делать по таймеру с выборкой записей, измененных с момента последней выборки минус какое-то "буферное время", а события использовать лишь для того, чтобы не делать "холостые" обновления: если между тиками не произошло событий, то и обновлять нечего.
Лентяй
Ладно, это цветочки. А что вот с этим делать?
Предположим мы исхитрились и написали обработчик Event-ов для такого select-а (для конкретного select-а проблема решаемая, а вот универсальное решение, как я говорил - мини-сервер на клиенте . Дальше начинаем издеваться над пользователем:
Удаляем запись из Tbl2 и, о чудо, - у соседа добавляется тысченка-другая записей в гриде. Класс, теперь вставляем другую запись в Tbl2 - у соседа пропадет сколько-там записей из грида. Или вааще все. А теперь корректируем значение какой нибудь записи - у соседа какая-то часть записей пропадает, и еще сколько-то добавляется...

Реальный пример этого случая мне в голову не пришел, но не важно - мы же рассуждаем теоретически. Такой запрос не сделает то же самое, но без подзапроса:
? Это вопрос: проверяю, правильно ли я усвоил тынц .
Как я написал выше, удаление я не рассматриваю: в моем случае удаление отсутствует по причине необходимости репликации, а лог вести не хочется. К тому же, желательна необходимость восстановления недавно удаленных записей. Так что удаление делается пометкой записи на удаление. Время от времени записи, помеченные на удаление "давно" удаляются физически. Вообщем, типичный проктологический способ. Невозможность вставки записи с такими же значениями уникальных полей, что и у помеченных на удаление записей не считается проблемой.
А что мешает помечать записи в запросе?
Разумеется, обновляющая выборка должна выбирать как помеченные, так и не помеченные на удаление записи.
Далее все сводится к предыдущему случаю, который сводится к случаю с одной таблицей (но в общем случае уже без отслеживания соответствия версий событиям).
А вот проблема с тем, что одновременно может измениться большое количество записей - это реальная проблема, согласен. В этом случае можно делать так:
Полностью согласен, что каждый запрос должен рассматриваться индивидуально в базе. А вот клиента универсальным вполне можно сделать. ;-)
Лентяй
Вообщем на select-ах чуть сложнее палки и веревки проктология становиться все очевиднее...
Покупал я сканер сестре недавно. Выбрал по инету подходящую модель со слайд-модулем. В одной комп. фирме ее не оказалось и мне стали впаривать совершенно другую: более старую, более дорогую и без слайд-модуля. Все свелось к попытке убедить меня, что слайд-модуль не так уж и нужен, что сестра вполне может обойтись и без него. Справедливо? Да, наверное. Да, в фотолаборатории сделают все качественнее, чем получится на слайд-модуле бытового сканера. Но в итоге заказ был сделан в другой фирме, где этой модели также не было: ее без лишних вопросов поставили в заказ и через некоторое время привезли.
Отсюда вывод: заказчика не должны интересовать технические проблемы исполнителя. :)