Добрый вечер всем.

Если заносить изменения в БД одним клиентом, то второй (третий и т.п.) эти изменения увидит только после обновления DataSet’а.
Вопрос, есть ли в MSSQL 2008 инструменты с помощью которых в нужный момент (например через хранимую процедуру) можно отправить всем клиентам сетевое уведомление, чтоб те обновили DataSet?

aleks2Гость5Добрый вечер всем.

Если заносить изменения в БД одним клиентом, то второй (третий и т.п.) эти изменения увидит только после обновления DataSet’а.
Вопрос, есть ли в MSSQL 2008 инструменты с помощью которых в нужный момент (например через хранимую процедуру) можно отправить всем клиентам сетевое уведомление, чтоб те обновили DataSet?

Есть, называется столбец rowversion (timestamp).

Доброе утро.

Не совсем понимаю о чём речь, может завалялся примерчик))) или есть ссылка на хорошую статейку.
Если несложно в двух словах напиши как это работает (принцип работы).

Сейчас все манипуляции с данными идут через хранимые процедуры, есть табличные переменные. В самой простой форме можно сказать, что идёт создание или обновление документа "один-ко-многим" т.е. в процедуре фактически полный цикл транзакции. В процедуре может обновиться от 1-й до 100-200 строк, но после этого клиент должен получить сетевое уведомление о том что определённая таблица изменилась (хотя по ней может измениться не одна строка), для того чтобы обновить DataSet. Клиент написан на DelphiXE6 + FireDAC.

Если смотреть на идеальный вариант, то неплохо бы передать произвольный сетевой пакет клиенту, в котором можно отразить например несколько параметров + название подсистемы, которая её вызывает, по этим данным можно судить какой датасет обновлять

aleks2Гость5Если смотреть на идеальный вариант, то неплохо бы передать произвольный сетевой пакет клиенту, в котором можно отразить например несколько параметров + название подсистемы, которая её вызывает, по этим данным можно судить какой датасет обновлять

Если смотреть идеальный вариант - надо не фантазировать, а надо реально смотреть на вещи.
Невместно серверу париться за клиента и чего-то там ему слать.
Чем придумывать фсякие query notifications - лучше сделать простой механизм запроса клиентом наличия обновлений в таблице.
И пущай клиент париться за "обновили-необновили".

Сейчас это есть. Сделано было неплохо. Сам проект двух-звенка, но, написана ещё служба, которая следит за сетевыми обновлениями + авто обновлением программы. Т.е. проект и не двух-звенка и не трёх, что-то между)))
Хотим исключить лишнее (на наш взгляд) звено в проекте т.к. из-за службы появились нюансы. Сейчас надо понять, можно ли эти функции возложить на MSSQL 2008 или выше или оставить как есть

aleks2,

если как предлагаешь ты ))) спамить лишний раз сетку - это уж совсем криво, особенно если одновременно с базой будут работать 100-200 клиентов

baracs,

я же писал!

Если смотреть на идеальный вариант, то неплохо бы передать произвольный сетевой пакет клиенту, в котором можно отразить например несколько параметров + название подсистемы, которая её вызывает, по этим данным можно судить какой датасет обновлять

Сон Веры ПавловныГость5,

в ADO.Net для таких целей используется класс SqlDependency , который, по сути, является оберткой над query notifications . Поскольку у вас Delphi, то нужно будет вручную настроить Query Notification , и запускать цикл ожидания оповещений в отдельном клиентском трэде.

Добрый день,

смотрю Вашу идею, чтоб включить её использую ALTER DATABASE <your db name> SET ENABLE_BROKER
Вопрос, это сказывается на производительности? я правильно понимаю, это что-то типа механизма обратных вызовов?

prog123,

Спасибо,
именно это сейчас изучаю, хочу понять как это всё работает