Есть клиент-серверное приложение.
Как реализовать  оповещение (перечитать данные)  всех клиентов присоединённых к БД в данный момент времени при изменении данных в таблицах.  Если один из клиентов  изменил данные, у других подключенных клиентов они  должны обновиться.

О, ещё один.
Не пора ли FAQ организовать уже?

> Если один из клиентов  изменил данные, у других подключенных
> клиентов они  должны обновиться.


А это, если их милльон клиентов ?

> А это, если их милльон клиентов ?


У каждого из миллиона клиентов обновить весь миллион записей на клиенте.
И пофигу, что сервер ляжет. Зато увидим изменения.

> Ega23  (18.08.2011 17:47:03)  [3]

Да ну, а нафига мне чужие изменения.

Куратор (один из клиентов) проекта добавил задачу, после этого она автоматически в реальном времени должна отобразиться у исполнителя (другой клиент)

> автоматически в реальном времени должна отобразиться у исполнителя
подвести исполнителя к компу и ткнуть носом....

но исполнитель один, пара, группа
а зачем всем?
> у других подключенных клиентов они  должны обновиться.

sms посылай.

> sniknik  (19.08.2011 09:25:06)  [6]

Подумают, что SMS вымогатель

с чего бы? своим да не донести, что с определенного номера, с определенной фразой типа "срочно на рабочее место лентяй!" означает не вымогательство, а "пожелание" пойти наконец то проработать???

после пары лишений зарплаты научатся думать правильно.

или
«Опять этот спам!» - сказал админ, разрывая повестку в военкомат.

выгоднее конечно "под дурачка" косить, типа ничего не знаю "хреновая sms"... с таких по две зарплаты.

Если клиент висит в трее при поступлении новой задачи, например подать звуковой сигнал

если "клиент висит в трее" то чем вопрос? пусть и проверяет задачи периодически... раз в пять мин. например. или посылай ему с "посановщика задач" событие (UDP например) по которому он должен проверить.
главное адресно, а то если каждый каждому будет все свои изменения стать... то в итоге любая сеть "ляжет".

> [11] sniknik ©   (19.08.11 10:22)
> или посылай ему с "посановщика задач" событие (UDP например)
> по которому он должен проверить.

Можно ещё ID записи с задачей приложить. В базе ведь должно быть кто кого курирует. Получится вместо
1000 кураторов * 100000 исплноителей = 100000000 запросов, в каждом запросе * количество задач
всего 100 запросов по одной задаче. Примерно так как-то.

можно посмотреть компонненты одак
идею и реализацию
там есть уведомление набора об изменении

> SQLEXPRESS   (20.08.11 01:17) [13]
>
> можно посмотреть компонненты одак
> идею и реализацию
> там есть уведомление набора об изменении
>

Ну а дальше что?

> Ну а дальше что?

зависит от хотелки

один раз сделал обновление набора налету
работало это странно, конечно. Но по т.з. почти

т.е. сидит юзер, смотрит в дбгрид, ничего не делает,
а там строки меняются..

да, потом все же переубедил
сделали как надо - нажал кнопку, получил новые данные

потом пляски с апдейтами пошли зато.
если два запросили строку и один изменил на одно, а другой на другое
то сделал, что второму выскакивало сообщение
типа, такое дело:
ты написал 1,
было 0,
но кто уже исправил на 3
и предлагалось выбрать окончательный вариант.
Причем, рекурсивно, т.е. если пока юзер думает какой вариант ему писать в бд, кто еще раз изменит, его опять спросит
ты написал 1,
было 0,
но кто уже исправил на хххх

т.е., теоретически,  человек мог всю жизнь выбирать, если запись будет постоянно меняться (скриптом, например)

> SQLEXPRESS  (20.08.2011 04:32:15)  [15]

Смотрит, раз и потерялась строка на которую смотрел, снова надо искать

> [16] SQLEXPRESS   (20.08.11 04:53)

У вас записей на всех не хватало что ли? С утра очередь на редактирование занимали? 8-)

Я придерживаюсь мнения, то при редактировании надо сначала ставить блокировку. Чтобы другой чел, если хочет изменить, знал - что уже кто-то что-то там изменяет (и, возможно, надо сначала томУ пользователю подойти, и попросить не заниматься фигнёй)