всем привет! Необходимо, чтобы все подключенные приложения получали сообщения об изменениях в БД-как это сделать?   

Пишешь триггер на insert и update. В нем постишь в какую-нить свою таблицу например tblChange значения. В программах клиентах периодически обновляешь данные. Тобишь 
И смотришь разницу. 

Это то можно сделать. Но мне необходимо, чтобы программки обновлялись по событию. Наверно, эта СУБД проблему не решает. 

В принципе реально, но гемор будет еще тот! Можно через системную процедуру запускать внешний исполняемый файл который будет кидать message твоей проге. 
Думаю, лучше обновлять информацию через некоторые периоды. 

По крайней мере другого пути не вижу. 

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

А я и говорю как это может решить СУБД.  

Она то решает, но не до конца. Все равно надо создать свой модуль, работающий по какому-то(наверно UDP) протоколу. А каждый клиент должен быть настроен на этот протокол. 

Ну извини, телепатический адаптер человечество еще не разработало. А твоя задача в принципе очень редкая. Еще ни разу не встречал такой необходимости.  

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

Это относится к категории "неправильно спроектированных задач". Теория сего такова:



Т.е. задачу можно решить, написав например extended SP с UDP broadcast, или отсылкой по email данных, или вызовом приложения... но в реальной жизни таких задач быть не должно, это противоречит клиент-серверной технологии и элементарным правилам защиты данных. Любой грамотный сисадмин на сервак поставит firewall который не допустит НИКАКИХ возможностей того чтобы сервер сам чего-то куда-то посылал. Появление такой задачи однозначно свидетельствуют о непродуманной и ошибочной архитектуре. Задача из разряда: 

- Мне надо забивать микроскопом гвозди
- Дык он для этого не предназначен
- Но мне всё равно надо, у меня задача такая. 

Может быть. Но, например, как тогда решить задачу, когда должно в РЕАЛЬНОМ масштабе времени отображаться на клиенте состояние датчиков(вкл. и выкл.). Обновление в БД происходит по какому-то отдельному каналу, о котором клиент и не знает. Он общается только с БД. Можно делать бесконечные запросы, но моя задача на несколько порядков сложнее и пустая трата процессорного времени может выйти боком(к тому же в моей системе запросов придется делать очень много и достаточно емкая обработка получится). Да и требования для систем реального времени достаточно высоки. Остается только-обновление по факту. Может еще есть какой-то способ, но мне он неизвестен? 

Live query, dynamic cursor, какой язык программирования на клиенте? 


PS. Системы реального времени и реляционные базы данных... кхе... кхе... что-то тут не так... Это мало совместимые вещи, т.е. конечно асфальтоукладчик можно использовать в формуле 1, но результат будет не очень впечатляющий...

Моё решение: есть канал по которому приходят данные, добавляем туда свой tier, делаем трёхзвенку, данные приходят на промежуточное приложение, это промежуточное приложение во-первых рассылает UDP пакеты (или обновляет связанных с ним по DCOM/CORBA/MIDAS клиентов), а во вторых заносит данные в базу данных. База данных должна быть тупиковым элементом системы, а не промежуточным... Хотя я могу не понимать специфики данной системы... 

Язык Visual C++. Реляционная БД очень часто встречается в таких системах(может, как говорится, "так сложилось исторически"). Клиентов может быть много, каналов связи тоже и все могут править БД. Про промежуточное приложение я тоже подумываю, если все будут через него общаться с БД-тогда вопрос будет решен. Так наверно и сделаю.