Возьмем к примеру 1С:
При добавлении записи в справочнике, документе и.т.д.
она сразу же появляется у всех пользователей.
Как это реализовано?
Например я пишу программу (ADO,MSSQL), и такого обновления
не происходит, пока не закрою-открою таблицу или не повторю запрос.
Может это где в свойствах есть? Или они сообщение какое-нибудь посылают?
Спасибо.

Здравствуйте, Аноним, Вы писали:

А>Возьмем к примеру 1С:
А>При добавлении записи в справочнике, документе и.т.д.
А>она сразу же появляется у всех пользователей.
А>Как это реализовано?
А>Например я пишу программу (ADO,MSSQL), и такого обновления
А>не происходит, пока не закрою-открою таблицу или не повторю запрос.
А>Может это где в свойствах есть? Или они сообщение какое-нибудь посылают?
А>Спасибо.

Есть такие операторы как rollbak — откатить транзакцию
и commit — фиксировать транзакцию.
Так и реализовано

Здравствуйте, magos, Вы писали:

M>Здравствуйте, Аноним, Вы писали:

А>>Возьмем к примеру 1С:
А>>При добавлении записи в справочнике, документе и.т.д.
А>>она сразу же появляется у всех пользователей.
А>>Как это реализовано?
А>>Например я пишу программу (ADO,MSSQL), и такого обновления
А>>не происходит, пока не закрою-открою таблицу или не повторю запрос.
А>>Может это где в свойствах есть? Или они сообщение какое-нибудь посылают?
А>>Спасибо.

M>Есть такие операторы как rollbak — откатить транзакцию
M> и commit — фиксировать транзакцию.
M>Так и реализовано

Насколько я знаю, транзакции служат для безопасного изменения данных (хотя не только).
Это изменит данные, например в DBGrid без переоткрытия таблицы?

Здравствуйте, <Аноним>, Вы писали:

А>Как это реализовано?
Если "по правильному", то периодический опрос сервера на предмет изменений.

А>Может это где в свойствах есть? Или они сообщение какое-нибудь посылают?
В свойствах нет и быть не может.
В принципе если очень хочется, то есть некий сервис, не помню уже как это называется, который какую-то нотификацию делает, но это все от лукавого, по большому счету...
Строго говоря любая нотификация со стороны сервера — это нарушение самого принципа клиент-серверной архитектуры, так как сервер на это время сам по сути становится клиентом.
В больших, "правильных" системах подобной нотификацией занимается третье звено, если же его нет, то периодический опрос сервера ну или на крайняк собственная реализация какого-нибудь механизма нотификации, но последнее как правило не есть гуд и нужны очень серьезные пичины, чтобы на это заморачиваться...

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, <Аноним>, Вы писали:

А>>Как это реализовано?
M>Если "по правильному", то периодический опрос сервера на предмет изменений.

А>>Может это где в свойствах есть? Или они сообщение какое-нибудь посылают?
M>В свойствах нет и быть не может.
M>В принципе если очень хочется, то есть некий сервис, не помню уже как это называется, который какую-то нотификацию делает, но это все от лукавого, по большому счету...
M>Строго говоря любая нотификация со стороны сервера — это нарушение самого принципа клиент-серверной архитектуры, так как сервер на это время сам по сути становится клиентом.
M>В больших, "правильных" системах подобной нотификацией занимается третье звено, если же его нет, то периодический опрос сервера ну или на крайняк собственная реализация какого-нибудь механизма нотификации, но последнее как правило не есть гуд и нужны очень серьезные пичины, чтобы на это заморачиваться...

Спасибо.
А можно подробней про 3 звено? Как оно функционирует?
У 1С это как-то работает, при этом с большими базами и практически без задержек.
Можно конечно, создать маленькую таблицу и каждое время (а если обновление нужно каждые 5 сек?) проверять значение какого-нибудь поля, которое изменять при добавлении записи.
Можно так же добавить какой-нибудь модуль, который будет отсылать всем сообщение при изменении базы.
Но вероятно существуют более, скажем, оптимальные методы для этого?

Здравствуйте, Аноним, Вы писали:

А>А можно подробней про 3 звено? Как оно функционирует?
Ну, на эту тему можно целую библиотеку написать..
Для начала могу отослать вот к этому топику: http://rsdn.ru/?Forum/?mid=289993

Автор: BalTun
Дата: 07.06.03

и в частности вот к этому сообщению: http://rsdn.ru/Forum/Message.aspx?mid=293317&amp;only=1

Автор: scaramush
Дата: 11.06.03

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

А>У 1С это как-то работает, при этом с большими базами и практически без задержек.
Понятия не имею, слава богу, с 1С пока не сталкивался, но послухам — далеко не та программа на которую стоит равняться...

А>Можно конечно, создать маленькую таблицу и каждое время (а если обновление нужно каждые 5 сек?) проверять значение какого-нибудь поля, которое изменять при добавлении записи.
Не самый плохой вариант кстати.

А>Можно так же добавить какой-нибудь модуль, который будет отсылать всем сообщение при изменении базы.
Можно.

А>Но вероятно существуют более, скажем, оптимальные методы для этого?
А это и есть те самые оптимальные методы...

Я давно уже пытался проанализировать как работает 1с

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

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

До экспериментов с удалением элемементов я не добрался.


Но то что нужно в подобных ситуациях использовать событийную модель а не переиодеские нотификации. Это факт.
Или я не прав?

Здравствуйте, Аноним, Вы писали:

А>У 1С это как-то работает, при этом с большими базами и практически без задержек.
А>Можно конечно, создать маленькую таблицу и каждое время (а если обновление нужно каждые 5 сек?) проверять значение какого-нибудь поля, которое изменять при добавлении записи.

Почему как-то? Открвываем 1С Сервис-Параметры и смотрим "Период опроса изменения Базы Данных (сек.) 10" . Вот тебе и ответ по поводу как в 1С.

З.Ы. Да кстати опрашивает она тока активную таблицу...

Здравствуйте, Аноним, Вы писали:

А>У второго он появиться только после того как второй хотябы сделает переход между уже имеющимися элементами в группе.
IMHO переход к другому элементу из только что созданного — это и есть добавление записи.

Нет, в терминах 1С добавление новой записи и переход на следующую — это разные понятия. И вообще, чистый имхо, что все эти обновления, нотификации — это всё мишура на елке, за этой мишурой иногда забывают про красивые елочные игрушки, а иногда и про саму елку

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, <Аноним>, Вы писали:

А>>Как это реализовано?
M>Если "по правильному", то периодический опрос сервера на предмет изменений.

"по правильному" — похоже потому, что 'широкий' спектр обслуживаемых системой (1C) БД
dbf, MS SQL Server и что там ещё ...
отсюда игнорирование многих возможностей ...
Если прога реализавана к MS SQL Server, то можно и пореальнее сделать ...
используя возможности MS SQL Server
От задачи всё зависит ...

Здравствуйте, ale-805, Вы писали:

A8>Нет, в терминах 1С добавление новой записи и переход на следующую — это разные понятия. И вообще, чистый имхо, что все эти обновления, нотификации — это всё мишура на елке, за этой мишурой иногда забывают про красивые елочные игрушки, а иногда и про саму елку

Не, я имел ввиду, что там наверняка сделан такой же грид, как, скажем, в MySQL Front. Типа пустое поле в конце грида -> вносишь данные -> жмешь стрелку вверх или вниз -> данные вносятся.

Здравствуйте, KGP, Вы писали:

M>>Если "по правильному", то периодический опрос сервера на предмет изменений.
KGP>"по правильному" — похоже потому, что 'широкий' спектр обслуживаемых системой (1C) БД
KGP>dbf, MS SQL Server и что там ещё ...
"по правильному" — имелось ввиду вообще, вне зависимости от конкретного приложения. Понятия не имею как это в 1С сделано.
Оповещение о внесенных изменениях это вообще не дело сервера, и если подобная функциональность вдруг потребовалась от СУБД, то с вероятностью 99% причина в кривом дизайне приложения.

KGP>Если прога реализавана к MS SQL Server, то можно и пореальнее сделать ...
KGP>используя возможности MS SQL Server
"пореальнее" — это не заставлять сервер ерундой заниматься. Не его это работа, он в принципе, по природе своей, для подобных вещей не предназначен.

Здравствуйте, Аноним, Вы писали:

[]
На вскидку могу предложить несколько способов реализации данного механизма:
1. Как говорил Merle периодический refresh.

2. Завести табличку в которую триггерами скидывать информацию о таблице, в которой произошло изменение,
тип изменения (I,U,D), информацию достаточную для идентификации измененной записи, и дату+время изменения.
Далее на клиенте(а лучше в 3-ем звене) обращаться, вытягивать идентификаторы измененных записисей с момента последнего обращения и отражать в интерфейсе.

2.1 Чем хорошо это делать на 3-м звене, да тем, что можно например для платформы Windows использовать COM/COM+. (EventSink-и, MS Message Queue Server и т.д.) формировать некий пакет и отдавать его клиенту в готовом виде. Клиенту остается только отобразить изменения.

3. Использовать специфические возможности сервера БД. Для Oracle например механизмы именованных каналов или Advanced Queuing.

4. Вырожденный вариант 2. Использование UDP + udf (interbase), extended stored proc (MSSQL) в триггере.
Но здесь можно столкнутся с проблемами не гарантированной доставки сообщения, асонхронности и т.д.

5. ...
6. ...
.
.
.
N. ...

Короче, вариантов и их комбинаций уйма. И каждый вариант нужно рассматривать по отдельности для каждой задачи.

Здравствуйте, LG, Вы писали:


LG>2.1 Чем хорошо это делать на 3-м звене, да тем, что можно например для платформы Windows использовать COM/COM+. (EventSink-и, MS Message Queue Server и т.д.) формировать некий пакет и отдавать его клиенту в готовом виде. Клиенту остается только отобразить изменения.
Если есть бизнес уровень, то все изменения и так через него идут, поэтому в этом случае длать опрос базы — лишняя работа, среднее звено и так знает, что изменения прошли и тут же может сделать необходимую нотификацию.

LG>4. Вырожденный вариант 2. Использование UDP + udf (interbase), extended stored proc (MSSQL) в триггере.
LG>Но здесь можно столкнутся с проблемами не гарантированной доставки сообщения, асонхронности и т.д.
Вот необходимость в использовании подобных вещей я и считаю кривым дизайном.

На самом деле вариантов всего два:
1. Если приложение чистый клиент-сервер, то периодический опос базы на предмет изменений.
2.Если же есть бизнес уровень, то это его задача.
Все остальное — детали реализации.

Здравствуйте, Merle, Вы писали:

[]

M>На самом деле вариантов всего два:
M>1. Если приложение чистый клиент-сервер, то периодический опос базы на предмет изменений.
M>2.Если же есть бизнес уровень, то это его задача.
M>Все остальное — детали реализации.

Согласен, но тема топика "Как реализовано динамическое обновление данных в прил...". Как раз и варианты реализации скорее всего и подразумевались Автором вопроса.
Если ответить на него однозначно
M>1. Если приложение чистый клиент-сервер, то периодический опос базы на предмет изменений.
M>2.Если же есть бизнес уровень, то это его задача.
думаю будет мало толку.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, KGP, Вы писали:

M>>>Если "по правильному", то периодический опрос сервера на предмет изменений.
M>"по правильному" — имелось ввиду вообще, вне зависимости от конкретного приложения. Понятия не имею как это в 1С сделано.
M>Оповещение о внесенных изменениях это вообще не дело сервера,
M>"пореальнее" — это не заставлять сервер ерундой заниматься. Не его это работа, он в принципе, по природе своей, для подобных вещей не предназначен.

а контроль о внесениях, чья забота ?
Интерееесно ...
Предположим, что MS SQL Server поддерживая тип поля timestamp, ерундой занимается
Ведь зачем обновлять данные, если поле типа timestamp не изменилось
Да и курсоры навернуты там вообще-то ...
Вот с добавлением оно похужее ...
хотя если не было удалений, может стоит запрашивать кол-во ?

Здравствуйте, KGP, Вы писали:

KGP>а контроль о внесениях, чья забота ?
Ты ничего не путаешь?

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

Здравствуйте, LG, Вы писали:

LG>Согласен, но тема топика "Как реализовано динамическое обновление данных в прил...". Как раз и варианты реализации скорее всего и подразумевались Автором вопроса.
LG>Если ответить на него однозначно
M>>1. Если приложение чистый клиент-сервер, то периодический опос базы на предмет изменений.
M>>2.Если же есть бизнес уровень, то это его задача.
LG>думаю будет мало толку.

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

Здравствуйте, Merle, Вы писали:

M>Контроль целостности и оповещение внешних, по отношению к серверу, приложенй о внесенных изменениях — это две большие разницы. Более того, второе, как уже было сказано, вообще не задача сервера БД.

MS SQL Server, поддерживая тип поля timestamp, даёт пользователю возможность узнать изменял ли кто запись за время 'от чтения этого поля записи ранне до текущего чтения'.
Это не контроль целостности и не прямое оповещение, а контроль за изменениями записи, а точнее обновление поля при любом изменении записи.
И за этим следит СЕРВЕР (можно и в триггере на UPDATE повесить свою реализацию ~timestamp, но всё равно это работа СЕРВЕРА, а не среднего звена в данном случае.
При репликациях это необходимая работа.

Здравствуйте, LG, Вы писали:

M>>На самом деле вариантов всего два:
M>>1. Если приложение чистый клиент-сервер, то периодический опос базы на предмет изменений.

опрос-опросу рознь ...

например, если надо узнать об изменениях 1-й записи, то можно timestamp использовать ...
считал, запомнил timestamp ...прошло время... запросил только timestamp — если изменился, то перечитал данные.
Но если у тебя прога и для mdb и для MS SQL Server, то использовать timestamp уже ...

Здравствуйте, KGP, Вы писали:


KGP>MS SQL Server, поддерживая тип поля timestamp, даёт пользователю возможность узнать изменял ли кто запись за время 'от чтения этого поля записи ранне до текущего чтения'.
KGP>Это не контроль целостности и не прямое оповещение, а контроль за изменениями записи, а точнее обновление поля при любом изменении записи.
KGP>И за этим следит СЕРВЕР (можно и в триггере на UPDATE повесить свою реализацию ~timestamp, но всё равно это работа СЕРВЕРА, а не среднего звена в данном случае.
KGP>При репликациях это необходимая работа.
Не, ты точно чего-то путаешь...
timestamp — это совершенно другой механизм, который к внешним приложениям имеет очень мало отношения, а уж к данной теме вообще никаким боком.
Когда timestamp на сервере меняется, сервер не бегает за всеми клиентами и не кричит "Мужики, у меня данные поменялись, обновляйтесь по бырому!".
Просто у клиента есть возможность определить самому менялись ли данные, а сервер просто их меняет, ну до кучи еще увеличивает timestamp никому об этом не говоря, а если вдруг какому-то клиенту стало интересно, то пусть сам придет и проверит, поменялись данные или нет.

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

Здравствуйте, Merle, Вы писали:

Вы очень категоричны в своих суждениях.
Например, в SQL Server есть механизм алертов, при помощи которого именно СЕРВЕР, сообщает(нотифицирует) клиентов.
И в принцепе, дело ли сревера или нет нотифицировать клиентов о чем бы то ни было, это зависит от конкретной задачи.

Здравствуйте, Vitaton, Вы писали:

V>Вы очень категоричны в своих суждениях.
Возможно.. Жизнь такая..
Просто я уверен в свой правоте, а уважаемый KGP, видимо немного не до понял сути обсуждения, вероятно, в том числе и по моей вине, из-за невольно дупущеной неточности в формулировках.

V>Например, в SQL Server есть механизм алертов, при помощи которого именно СЕРВЕР, сообщает(нотифицирует) клиентов.
Я упоминал о нем в одном из постингов в этой ветке. Это отдельный, самостоятельный сервис. Сейчас уже не помню, возможно он использует механзм репликации сиквела для генерации событий, но сути это не меняет.


V>И в принцепе, дело ли сревера или нет нотифицировать клиентов о чем бы то ни было, это зависит от конкретной задачи.
Безусловно зависит, но как я уже говорил в подавляющем большинстве случаев это worst practice.

Здравствуйте, Merle, Вы писали:
KGP>>MS SQL Server, поддерживая тип поля timestamp, даёт пользователю возможность узнать изменял ли кто запись за время 'от чтения этого поля записи ранне до текущего чтения'.
KGP>>Это не контроль целостности и не прямое оповещение, а контроль за изменениями записи, а точнее обновление поля при любом изменении записи.
KGP>>И за этим следит СЕРВЕР (можно и в триггере на UPDATE повесить свою реализацию ~timestamp, но всё равно это работа СЕРВЕРА, а не среднего звена в данном случае.
KGP>>При репликациях это необходимая работа.
M>Не, ты точно чего-то путаешь...

Ну прям как пластинка заела ...

M>Когда timestamp на сервере меняется, сервер не бегает за всеми клиентами и не кричит "Мужики, у меня данные поменялись, обновляйтесь по бырому!".

Вы, уважаемый читаете между строк ? Где я писал, что 'сервер бегает за всеми клиентами'

M>Просто у клиента есть возможность определить самому менялись ли данные, а сервер просто их меняет, ну до кучи еще увеличивает timestamp никому об этом не говоря, а если вдруг какому-то клиенту стало интересно, то пусть сам придет и проверит, поменялись данные или нет.

И чем это высказывание разнится от :
KGP>>MS SQL Server, поддерживая тип поля timestamp, даёт пользователю возможность узнать изменял ли кто запись за время 'от чтения этого поля записи ранне до текущего чтения'.
KGP>>Это не контроль целостности и не прямое оповещение, а контроль за изменениями записи, а точнее обновление поля при любом изменении записи.

M>А здесь обсуждается как сделать и надо ли делать так, чтобы сервер сам извещал клиентов о том, что данные поменялись.
Обсуждалось, КАК реализовать слежку за изменениями данных ...
M>Возможно я немного не ясно излагаю свои соображения, но это казалось мне очевидным.
Возможно, а что казалось очевидным , то что
'Возможно я немного не ясно излагаю свои соображения' ?

Здравствуйте, KGP, Вы писали:

Нда, что-то у нас с взаимопониманием бедулька какая-то...

KGP>Вы, уважаемый читаете между строк ? Где я писал, что 'сервер бегает за всеми клиентами'
А как еще понимать (-) на мои сообщения, в которых говорлось, что сервер бегать за клиентами не должен?
Я описывал принципы построения подобных механизмов, ты, как я понял, возражал, причем используя детали конкретной реализации.
Мало того, так еще и реализация страдает, так как timestamp годен для очень узкого круга задач, потому что отследить изменение нескольких записей или тем более вставку с его помощью проблематично.


M>>А здесь обсуждается как сделать и надо ли делать так, чтобы сервер сам извещал клиентов о том, что данные поменялись.
KGP>Обсуждалось, КАК реализовать слежку за изменениями данных ...
Угу, но я описывал общие принципы построения, а ты какую-то конкретную реализацию, при этом вроде бы как ты со мной не согласен, но в чем и почему не понятно.


Ладно, давай в дальнейшем постараемся более четко выражать свою позицию, во избежание подобных, очевидно бесмысленных споров по причине взаимных непоняток.