Мне кажется, что в данном случает вовсе не POST_EVENT нагрузит сервер... :)

Прежде всего - сколько у тебя "одновременных" клиентов?

И, во-вторых, интересно: что же именно ты собираешься показывать после изменений разного типа. Например, при отображении отсортированного списка, были удалены все записи, которые были видны на экране - что ты станешь показывать?

Вообще, технически проблем нет.

Однако:

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

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

Описаны на последовательность "сначала а, потом б", а взаимоисключающие варианты - "либо а, либо б".

Вариант а) - использование собственной системы оповещений (с помощью Mailslots Windows, в данном случае).
Вариант б) - использование системы событий Interbase (POST_EVENT...).

Никакого, наверное. Ну я и не предлагал это делать, я спросил нечто иное:

...


Нормально тогда, наверное. У нас две-три сотни "параллельных" клиентов по такой схеме работает. Конечно, не "DataSet.Refresh()" - клиенты бы сразу удивились...

Это была очень плохая мысль. По многим причинам.
Да это просто п....ц, а не "плохая".

Вообще-то, именно об этом я тебя и спросил...

Ну так реши, как это должно выглядеть, и сделай. Может, тебе действительно .Refresh() будет достаточно.