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

Так вот, сделать обновления по insert и update можно следующим способом:

1. на ПК у нас и так есть генератор, как правило. Так вот, когда мы получаем записи, автоматически сканируем столбец первичного ключа, и запоминаем максимальное считанное. Теперь, для получения вставленных с этого момента записей можно выполнить запрос
select * from table
where pkfield > :saved_pkfield_value and pkfield <= gen_id(pk_gen, 0)

то есть, от запомненного на последнем считывании, до текущего генератора
(понятно что до "текущего" записи могут не считаться, если они не committed).
Опять запоминаем максимальное значение ПК из полученного набора записей, и так по кругу.
(тут бы и добавить эти записи в буфер клиентдадасета)

2. для отлова обновлений делаем дополнительный столбец таблицы, который на before update заполняется еще одним генератором.
Схема аналогична изложенной выше, то есть - при вставке инкрементируется ПК, а при обновлении - этот столбец. Вторым запросом, похожим на предыдущий, вынимаем свежеобновленные записи.
(Тут бы и обновить эти записи в буфере клиентдатасета)

3. для отлова удалений все несколько сложнее. Или на удаления надо положить, если их нет, или сделать отдельную таблицу, параллельную исходной, и при удалении складывать туда идентификаторы (pkfield) удаленных записей. Тут, правда, с генераторами ничего не выйдет, т.к. записи могут удаляться как попало, поэтому если требуется проверять "удаленные за сегодня", то надо добавить в ПК этой доп. таблицы еще и столбец типа DATE.
(тут бы и удалить эти записи в буфере клиентдатасета)

Комментарии?

да, добавлю, что это описание примера репликации, или рассылки изменений, на самом деле. то есть здесь никто "рефрешить", и тем более через евенты, не собирался :-) Есть сервак, а есть туча агентов, которые сами по себе, когда им надо, получают информацию об изменениях данных на сервере. Просто потому, что их предполагалось много, и если бы они по евенту ломанулись сразу на сервак, то ...
Собственно, еще более на самом деле это описание "серверного" приложения. Потому что клиент только сообщал, в каком он состоянии, а серверная аппликуха для него подгребала данные и отправляла.

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

Current_Transaction колонкой записи и в параметры евента и ВСЁ

ну дак нет же этого.

що буим делать с pkfield<:saved_pkfield_value которые в момент назначения его таковым не были ещё закоммиченными?

да ничего не будем! saved_pkfield_value это грубо говоря MAX(pkfield_value) из полученных. я ж там написал, специально, что на генератор ориентируемся как на теоретический максимум, а не на фактический.