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

О, ещё один.
Не пора ли 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-)

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

> Sergey13 ©   (22.08.11 10:10) [18]

кстати, совсем нет :)
Но в ТЗ было. Сначала так - сделал. Потом так сказали - тоже сделал.
А реально - ни разу похоже и не было таких случаев, судя по логам.


> Cobalt ©   (22.08.11 10:52) [19]

тоже за SELECT FOR UPDATE. И настроить на тайм-аут.
Смотреть - смотри, править - погоди пока поправят или до таймаута.

>Cobalt ©   (22.08.11 10:52) [19]
>Чтобы другой чел, если хочет изменить, знал - что уже кто-то что-то там изменяет (и, возможно, надо сначала томУ пользователю подойти, и попросить не заниматься фигнёй)

А вот с чего бы это двум операторам вздумалось менять одну и ту же запись в базе ? Один и тот же документ вводят (правят) ?

> А вот с чего бы это двум операторам вздумалось менять одну
> и ту же запись в базе ?

Рассчитываем на такое случай.
Приходят периодически N заявок. Сидит оператор и помечает их как принятые им.
Работа такая, принять, подумать в чей это власти сделать, переправить.
В то же время каждый сам может взять к исполнению.

Оператор открыл список поданных, ставит checkbox напротив тех, которые, как он думает, можно отправить одному человеку.
А тот человек не занят, тоже зашел, и берет первую же заявку. т.е. checkbox и принять.
Оператор в это время жмет принять(пока на себя).

Оператору должно выскочить
Заявка такая то уже взята тем-то. Что выбираешь, оставить как есть или взять себе?
Оставить как есть - он и так ему хотел отправить, можно и так.
а может взять себе и направить еще кому-то потом. Пусть 2 человека работают над ней, если ему кажется что тут один полностью не сможет выполнить. (как правило, доступ новому человеку отправляется админам сети и БД).

> А вот с чего бы это двум операторам вздумалось менять одну
> и ту же запись в базе ? Один и тот же документ вводят (правят)


Если вероятность этого существует, то надо закладываться. Практика показывает, что это лучше, чем потом всю логику менять.

> [22] OW ©   (22.08.11 13:02)
> а может взять себе и направить еще кому-то потом. Пусть 2 человека работают над ней

Как то ИМХО это плохо согласуется с одним checkbox-ом. Разве что у checkbox-а градации серого какие то реализованы. 8-)

> А тот человек не занят, тоже зашел, и берет первую же заявку. т.е. checkbox и принять.
> Оператор в это время жмет принять(пока на себя).
Почему бы эту исключительную ситуацию и не обрабатывать как исключительную ситуацию, т.е. по мере возникновения? Зачем кому-то что-то ПОСТОЯННО рассылать, а другому что-то ПОСТОЯННО принимать и анализировать присланное?

>Ega23 ©   (22.08.11 13:04) [23]
>Если вероятность этого существует, то надо закладываться. Практика показывает, что это лучше, чем потом всю логику менять.

Практика показывает, что логику менять все равно приходится. Как не "закладывайся". Ибо нет приема от лома, а защиты от дурака :)
Это к тому, что надо комбинировать алгоритмические методы с административными.

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


если подложить соломки в потенциально-опасном месте, то переделывать приходится мало. если не подстелить - то много.

Когда-то очень давно, когда я был юн и неопытен, делал одну халтурку. Ну там цены считало, то-сё.
Так вот. Был НДС. В ТЗ был указан. Всё замечательно. Но вот потом выяснилось, что есть ещё и НСП. Который у товара может быть, а может и не быть. И вот в этом магазине (внутри МКАД-а) он 6%, а в ста метрах от него (снаружи МКАДа) - уже 5.5%.
И надо это всё "быстренько" поменять, "ну чё там, ещё один налог добавить".

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

я ничего не понимаю, я делаю заявку - "не могу подключится к БД"

Первая линия помощи. Принимает заявку. Возможно, переспрашивает, есть ли коннект вообще. Просит пингануть сервер. Не знает в чем дело м.б., передает далее, например разработчику программы. Время разработчика дороже, его не заставляют самому лезть и отлавливать вопросы с его программой связанные, а потом учить где модем включается..
Но он может это сделать.

Как это выглядит: Табличка
checkbox[1] Текст1
checkbox[2] Текст2
checkbox[3] Текст3

Кнопка "принять"
выбрал пункты, нажал.

> надо комбинировать алгоритмические методы с административными.

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

> [27] OW ©   (22.08.11 15:31)
Судя по описанию - это служба поддержки какая то, а это уже маленький документооборотик получается. А это все равно сложнее трех (и даже пяти) чекбоксов. Тут иногда надо документ (заявку) несколько раз туда-сюда пересылать. Я бы и сделал как документ и его пересылки.
И вовсе тут информирования в реальном времени не требуется.
ИМХО.

> Sergey13 ©   (22.08.11 15:55) [29]

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

Второй пункт - тоже самое с номерами телефонов. Выкатывается список, оператор нащелкивает те, которые надо провести, как исправленные. (Есть такое понятие)

Второй оператор нащелкивает другие, как неисправленные,
Третий нащелкивает как требуют перепроверки.

Список с утра у них, под 1 000 строк, получается в результате анализа скриптом формальных параметров
А все люди (хотя иногда сомнения есть :)), могут один и тот же выбрать и там, и там (и там)..
Потому, надо предупредить.

>OW ©   (22.08.11 11:30) [20]
>тоже за SELECT FOR UPDATE. И настроить на тайм-аут.
для этого используются пользовательские блокировки, но никак не приемы, делающие БД однопользовательской

> Кщд   (23.08.11 07:55) [31]

какие это, например?

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

>OW ©   (23.08.11 08:30) [32]
>какие это, например?
какие примеры? for update
какие блокировки? так, пользовательские же)

> sniknik ©   (23.08.11 10:23) [33]

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


Кщд   (23.08.11 11:53) [34]

аа..что-то я не о том, наерное туплю.

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

таблицу искал, которую в другом месте, в другом проекте, другой базе завел - вот был испуг, что все куда-то исчезло вдруг и, причем, совсем без следов :)