AntonariyМожно так:
То есть нужно создать dll, которая будет генерировать событие, на которое должен подписаться клиент. Если клиент на том же компе, где и сервер, то проблем никаких. Если на другом, то есть два пути — негламурный и геморойный. В первом случае вместо события нужно рассылать винсоком пакеты, которые будут анализироваться клиентами. Во втором поднимать com+ и настраивать его события. Рекомендую первый.Есть еще третий путь. Но он доступен только избранным - использовать встроенную в сервер БД команду message to client (или что-нибудь подобное) а в клиенте ждать ее и по получению перезапрашивать обновленную часть данных. Но server push есть в ооочень редких базах данных. В MS SQL - этого нет.

proftsА собственно зачем вообще нужна dll. почему триггер, реагирующий на изменение/добавление в таблице сам не может генерировать событие?Может конечно, может и будет. От триггера ты никуда не денешься. Но это событие должно каким-то образом попасть на клиента верно? А если СУБД сама по определению не может ничего послать клиенту (она только отвечает на запросы!), то как ты собираешься делать эту самую посылку клиенту?

proftsНе могли бы привести пример какого-нибудь события в dll, на которое будет реагировать клиент?О господи! Не бывает событий в dll.

Событие случается в твоей базе данных - добавилась строка например. На таблице висит триггер. Этот триггер отследив что произошло добавление строки обращается к функции которая находится во внешней dll. В качестве параметра для этой функции передает список всех подключенных к базе в данную секунду клиентов и их IP адреса.
Функция проходит по всему списку клиентов, устанавливает с каждым клиентом TCP туннель и посылает по нему сообщение "такая-то таблица обновилась". (Если не хочешь с TCP туннелем возится, можешь ограничиться UDP пакетами, но они имеют право теряться. Подробнее читай учебник по сетям)

proftsТ.е. клиент постоянно должен быть в ожидании этого события?Да. Каждый клиент базы данных все это время сидит и ждет пока та самая функция из dll не попытается с ним связаться. А когда она связалась и сообщила что какая-то таблица обновилась, клиент должен будет посмотреть: а показывает ли он в данное время эту таблицу вообще или пользователь держит открытым другое окно. А потом из того-то же информационного пакета в котором приехало имя таблицы, клиент вытащит первичные ключи обновленных записей, и перезапросит эти записи с сервера. Потом добавит/удалит/изменит эти записи на визуальном отображении таблицы. После чего клиент заснет в ожидании следующей посылки по уже установленному каналу связи либо открытия нового канала.
И если ты еще не догадался - этот канал связи по которому сервер сообщает клиенту о появлении новых записей это совсем не тот же самый канал связи по которому клиент тянет данные с сервера. У тебя будет в итоге два канала. Один для данных, другой для событий на сервере.

Теперь понял? Или еще дальше разжевывать?
И сразу говорю - ни один DBGrid самостоятельно это все делать не умеет. И наборы компонентов которые умеют так работать стоят очень и очень большие деньги.

proftsИ насколько я понимаю это событие можно напрямую вызвать из MS SQL? Или оно должно наступать при обращении к dll?Ты никогда сам события не вызываешь. Вообще. На то они и события.
События случаются и они уже вызывают твои функции и процедуры.

proftsВообще изначально думал, что такая задача как обновление данных в клиенте - абсолютно обычная и простая задача, описание которой должно быть чуть ли не в первой главе каждого учебника.Ну не знаю насчет учебников, но задача в обычной постановке действительно очень простая: В такой постановке эта задача решается всеми и очень часто. Иногда шаг 3 заменяют на "Ждет пока пользователь не ткнет кнопку Обновить".
А если задача ставится так, чтобы сервер сообщал клиенту что данные обновились - вот тогда начинаются игры с дополнительными каналами связи. Читай выше.

proftsТогда вообще не понимаю где камень преткновения и что в данном случае будет стоить очень и очень большие деньги.если знаешь что и как - никаких камней :) Но чтобы это реально сделать тебе нужно быть одновременно и специалистом в базах данных (чтобы написать триггер) и специалистом в твоей конкретной СУБД (иначе не сможешь связать триггер с внешней dll) и уметь посылать сообщения по сети (чтобы написать эту самую dll) и уметь принимать эти сообщения... То есть это либо один универсал (а мы дорогие) Либо команда из нескольких человек.

proftsКак же другие это делают. Как пример на этом же форуме есть другая тема с такой же задачей. Там ее решили через блокировку таблицы (например) на сервере, триггер обравает блокировку, а клиент находится в ожидании обрыва.Ну а как именно клиент ждет обрыва этой самой блокировки? Механизм ожидания там какой?
И вообще, о какой блокировке в том топике шла речь? Если о транзакционных блокировках, то они триггером не обрываются в принципе и клиент ждет ответа всегда автоматически. Если самодельные блокировки подвластные триггерам - то опять вопрос: как клиент узнает что блокировка снялась? Тут только два пути - либо перезапрашивать постоянно, либо изобретать свою реализацию server push.