Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7   вперед  Ctrl      все
 Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 21765
Данная тема неоднократно поднималась на форуме и не только, например:

https://www.sql.ru/articles/mssql/02040201AlertServiceForSQLserv.shtml
https://www.sql.ru/forum/actualthread.aspx?tid=283541
https://www.sql.ru/forum/actualthread.aspx?tid=33168
https://www.sql.ru/forum/actualthread.aspx?tid=1146
https://www.sql.ru/forum/actualthread.aspx?tid=230433
https://www.sql.ru/forum/actualthread.aspx?tid=178810
https://www.sql.ru/forum/actualthread.aspx?tid=8775

В основном предлагались следующие решения:
  • Опрос.
    Ну кому надо оповещение, того опрос не устроит. Даже если клиенты будут опрашивать сервер каждые 10 секунд (а у меня их 30), сервер будет только этим и заниматься. К тому же, это создает нагрузку на каналы, некоторые клиенты у меня подключены через интернет.
  • NETSEND
    Не гарантирует доставку. На некоторых машинах он отключен. Не годится для интернет-клиентов.
  • Собственные системы оповещения через TCP/IP. Собственно, у нас так было и сделано до текущего времени, но в связи с наличием интернет-клиентов пришлось реализовывать это как специальный прокси-сервер, потому что некоторые интернет-клиенты не имеют прямого IP, сами находясь за файрволами, и по инициативе сервера с ними соединиться нельзя, приходится организовывать и поддерживать дополнительные клиентские соединения. Т.е. решение получилось достаточно громоздким, к тому же приходилось делать дополнительные настройки файрвола для организации этих дополнительных коннектов.
  • Notification Services - боюсь прокомментировать, насколько могу судить, решение тяжеловесное, да и предназначено немножко для других целей.

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

    Принцип следующий:

    1) На клиенте есть процедура инициализации соединения. Она запускается при старте клиента и создает объект Connection, предназначенный специально для оповещения, его нельзя использовать для других целей. В этой процедуре клиент уведомляет сервер о собственном подключении и сервер регистрирует у себя в таблице подключенных клиентов SPID этого соединения.

    2) Создается объект Command, которому устанавливается таймаут, скажем, 10 мин. На этом объекте АСИНХРОННО запускается процедура сервера, в которой находится единственная команда
    waitfor delay '00:09:50'.
    Т. е. Command становится в режим ожидания окончания процедуры, а клиентский код продолжает выполняться.

    3) Когда сервер хочет возбудить событие на клиенте, он убивает его соединение (командой KILL)

    4) Клиент отлавливает событие ExecuteComplete, возникающее в выделенном Connection-е. Если adStatus = adStatusOK, это значит закончилось десятиминутное выполнение процедуры ожидания и надо запустить ее заново. Если же возникла ошибка - клиент считает это получением оповещения, выполняет необходимые действия и заново запускает процедуру инициализации Connection, поскольку Connection убит сервером.

    Событие на клиенте возникает мгновенно. Трафик между клиентом и сервером во время выполнения процедуры ожидания не идет.


    Вот, собственно и все. Система проверена в рабочем режиме на ADO2.8 и SQL2000. Если кого заинтересует, могу опубликовать код. Обнаружены следующие недостатки данного подхода.
  • процесс, в результате работы которого должно возникнуть оповещение, должен иметь права процессадмина чтобы выполнить команду KILL, права на которую не могут быть делегированы. Впрочем, процессадмины имеют право только на KILL и на назначение этих прав другим пользователям, что опять же ограничивается командой KILL.
  • KILL не может быть использована внутри транзакции (в частности - в триггере). Если есть необходимость использования оповещения из триггера, можно запустить KILL отдельным процессом через sp_start_job.
  • если по каким-то причинам клиент не получит хотя бы одного события ExecuteComplete, то он перестанет следить за событиями сервера, так как процедура ожидания не запустится заново. В частности, это может произойти у программиста при работе с отладчиком, когда событие возникло, а клиентское приложение было в режиме паузы. Ну и на ADO стопроцентной надежды нет, в асинхронном режиме работает из рук вон плохо. Я сделал так - на имеющийся у меня ежеминутный (для других целей) таймер повесил проверку, если вдруг объект Command не находится в режиме adStateExecuting, то запускается процедура инициализации соединения.

    Жду конструктивной критики. Если критики не будет, настаиваю на размещении в FAQ :)
  • 25 авг 06, 11:40    [3052649]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    GreenSunrise
    Member

    Откуда:
    Сообщений: 12310
    У меня вопрос. Не по конкретному решению, а вообще по теме уведомлений.

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

    Скажите, что вы будете делать, если у вас таких изменений будет ну очень много? Сотни транзакций в секунду? Получать уведомление и перезачитывать данные из таблицы (вариант - не всю таблицу, а, к примеру, только записи с теми id'шниками, которые в триггере обрабатывались)? Вы твердо уверены в среднем количестве транзакций за единицу времени и возможность, что система "захлебнется", исключена?

    Что вы будете делать в случае действий над данными, которые не проходят через триггеры? Ну, к примеру, bcp с отключенной опцией FIRE_TRIGGERS?

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

    Понятно, что случай с bcp решается на ура путем вставки вызова процедуры уведомления после отработки заливки данных. А вот уведомления об изменениях в данных кто куда пихает? Все-таки в триггеры?
    25 авг 06, 11:58    [3052775]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда: Moscow
    Сообщений: 37069
    GreenSunrise
    меня очень интересует, как люди решают описанные выше проблемы. Или, возможно, игнорируют их.

    Кнопка Refresh - рулит. :)
    25 авг 06, 12:08    [3052852]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Shocker.Pro
    Member

    Откуда: ->|<- :адуктО
    Сообщений: 21765
    GreenSunrise
    Скажите, что вы будете делать, если у вас таких изменений будет ну очень много? Сотни транзакций в секунду?


    Во-первых, триггер производит анализ, и далеко не на все изменения посылает уведомления.

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

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

    Клиент мне подконтролен, так что глобальных операций вставки в таблицу не произойдет. А если даже случится ошибка и произойдет - см. п.3. Соответственно, операций с отключением триггеров в клиенте тоже нет.
    25 авг 06, 12:10    [3052871]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Shocker.Pro
    Member

    Откуда: ->|<- :адуктО
    Сообщений: 21765
    Гавриленко Сергей Алексеевич
    Кнопка Refresh - рулит. :)


    Меня убивают такие ответы. Задаешь вопрос - как организовать оповещение, а тебе отвечают: дурак ты, не надо тебе оповещение, клиент должен сам нажимать кнопку Refresh.

    Уважаемый Гавриленко Сергей Алексеевич, скажите когда вы пользуетесь аськой, вы нажимаете кнопочку Refresh, чтобы получить новые сообщения??? Или они сами к Вам приходят?

    Для остальных - я не собираюсь обсуждать вопрос целесообразности оповещения. Все, кто выступает против оповещения, просто никогда не сталкивались с такими задачами, когда оно ТРЕБУЕТСЯ. А те, кто сталкивался - никогда не будут говорить про опрос или принудительное обновление.
    25 авг 06, 12:17    [3052933]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда: Moscow
    Сообщений: 37069
    Shocker.Pro
    Гавриленко Сергей Алексеевич
    Кнопка Refresh - рулит. :)


    Меня убивают такие ответы. Задаешь вопрос - как организовать оповещение, а тебе отвечают: дурак ты, не надо тебе оповещение, клиент должен сам нажимать кнопку Refresh.

    Объясните мне, что в моем посте Вас натолкнуло на мысль, что Вы - дурак, и не надо Вам это делать? Между прочим, отвечал я не на Ваш пост.
    25 авг 06, 12:22    [3052982]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    GreenSunrise
    Member

    Откуда:
    Сообщений: 12310
    Shocker.Pro
    Во-первых, триггер производит анализ, и далеко не на все изменения посылает уведомления.

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

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

    Клиент мне подконтролен, так что глобальных операций вставки в таблицу не произойдет. А если даже случится ошибка и произойдет - см. п.3. Соответственно, операций с отключением триггеров в клиенте тоже нет.

    Спасибо за ответ. Именно это и было интересно.
    25 авг 06, 12:24    [3053006]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    I
    Guest
    В Interbase есть готовое решение, а что по поводу реализации данного
    предлагает Microsoft? Описанный метод с соединениями, лично по моему мнению, плохо масштабируемое решение с плохо предсказуемыми последствиями применения в конкретных ситуациях. Вообще, интересная тема, нужно подумать над этим как следует.
    Первое, что пришло в голову - триггер (реагирующий на нужное событие), который прерывает ожидание в вызванной клиентом процедуре. Вызванная клиентом процедура возвращает параметры в таймере на клиенте и клиент получает уведомление о событии. Получаем возможность, автоматически завершать ожидание, при старте можно задать сколько ждать, например.
    Возможно, полный бред, не знаю, еще не проснулся...
    25 авг 06, 12:24    [3053012]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Shocker.Pro
    Member

    Откуда: ->|<- :адуктО
    Сообщений: 21765
    Приношу извинения. Дело в том, что практически во всех постах на эту тему (да и часто не на эту тоже) вместо ответа на вопрос люди начинают высказываться на тему, что неверно спроектирован подход. Если у меня будут сомнения в правильности подхода, я так и задам вопрос. Еще раз извините.
    25 авг 06, 12:25    [3053020]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Shocker.Pro
    Member

    Откуда: ->|<- :адуктО
    Сообщений: 21765
    I
    триггер (реагирующий на нужное событие), который прерывает ожидание в вызванной клиентом процедуре.


    ИМХО чтобы прервать процедуру, нужно, чтобы она выполняла какие-нибудь действия (например в цикле) - а это дополнительная нагрузка на сервер, в то время, как waitfor сервер не грузит.
    25 авг 06, 12:27    [3053040]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    DeColo®es
    Member

    Откуда: Москва
    Сообщений: 5499
    Блог
    GreenSunrise
    Скажите, что вы будете делать, если у вас таких изменений будет ну очень много? Сотни транзакций в секунду? Получать уведомление и перезачитывать данные из таблицы (вариант - не всю таблицу, а, к примеру, только записи с теми id'шниками, которые в триггере обрабатывались)?
    Как раз недавно реализовал оповещение по UDP. Проблема перегрузки сервера решается так:
    1) Клиент сам "подписывается" не только на события, но и на "уточнение внутри события". Процедура оповещения получает на вход это "уточнение" (например, id записи) и рассылает только тем клиентам, которые заинтересованы в этом событии с этим "уточнением". Соответственно в пакете передается это "уточнение". То есть изменение записи, на которую никто "не подписан", не вызовет даже потока сообщений от сервера. А в случае, если уведомление получено, не обязательно клиент должен "переспрашивать", что именно случилось - можно сразу запросить конкретные данные.
    Насчет bcp - у нас такая задача просто не стоит, да и невозможно "подписаться" на запись, которой еще нет. То есть подписаться-то можно, оповещалка к фактическим таблицам и данным не привязывается, но смысл? ;)
    25 авг 06, 12:32    [3053078]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    GreenSunrise
    Member

    Откуда:
    Сообщений: 12310
    Мне в описанном решении не нравится необходимость стабильного канала, где связь железно не оборвется сама. На нестабильных каналах совершенно неработоспособный подход. С учетом того, что сейчас народ часто пишет веб-клиентов, замечание существенное.

    Еще не нравится постоянное держание коннекта клиентами с точки зрения излишнего расхода ресурсов сервера. Получается, что при тех самых 30 юзерах, о которых сказал автор топика, 30 коннектов постоянно простаивают. Возможно, это копейки, но мне не нравится... А если у меня 200-500 постоянное работающих юзеров?
    25 авг 06, 12:35    [3053115]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Shocker.Pro
    Member

    Откуда: ->|<- :адуктО
    Сообщений: 21765
    DeColo®es
    1) Клиент сам "подписывается" не только на события, но и на "уточнение внутри события". Процедура оповещения получает на вход это "уточнение" (например, id записи) и рассылает только тем клиентам, которые заинтересованы в этом событии с этим "уточнением".


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

    Но UDP, насколько я знаю, не гарантирует доставку пакета.
    25 авг 06, 12:36    [3053122]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Александр Гладченко
    Member

    Откуда:
    Сообщений: 10730
    Блог
    TO Shocker.Pro

    ИМХО, решение представляет интерес для многих... Если захотите опубликовать в виде статьи, рассылка в Вашем распоряжении ;)
    25 авг 06, 12:36    [3053128]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Shocker.Pro
    Member

    Откуда: ->|<- :адуктО
    Сообщений: 21765
    GreenSunrise
    Мне в описанном решении не нравится необходимость стабильного канала, где связь железно не оборвется сама.


    Простите, а для работы с SQL-сервером разве не нужен постоянный канал? Или Вы работаете с отвязанным клиентом? Но даже если так, постоянный канал для оповещений В ЛЮБОМ СЛУЧАЕ НУЖЕН, потому что с некоторыми клиентами SQL-сервер не сможет связаться по собственной инициативе, чтобы уведомить их о событии. А я просто использую стандартное соединение на стандартном порту.
    25 авг 06, 12:39    [3053158]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    GreenSunrise
    Member

    Откуда:
    Сообщений: 12310
    2DeColo®es: тоже спасибо за ответ :-) Хотя автор и ждет критики именно технического решения, но хочется и такие вещи спросить тоже. Меня так они вообще больше интересуют, чем конкретная реализация.

    DeColo®es
    Насчет bcp - у нас такая задача просто не стоит, да и невозможно "подписаться" на запись, которой еще нет. То есть подписаться-то можно, оповещалка к фактическим таблицам и данным не привязывается, но смысл? ;)

    У вас другой подход к оповещению, судя по тому, что вы описали. Смысл в оповещении после bcp есть, если клиенты хотят получать уведомление о добавлении записей в таблицы. Если вам такое не нужно, то понятно, что и париться нечего :-)
    25 авг 06, 12:40    [3053165]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Shocker.Pro
    Member

    Откуда: ->|<- :адуктО
    Сообщений: 21765
    Александр Гладченко
    TO Shocker.Pro

    ИМХО, решение представляет интерес для многих... Если захотите опубликовать в виде статьи, рассылка в Вашем распоряжении ;)


    Добро, напишу статью с примерами кода на следующей неделе.
    1) хочу проверить на SQL2005
    2) хочу дождаться мнения Glory (ща как разнесет в пух и прах)
    3) в каком формате делать статью (html или коды форума?)
    4) куда кинуть?
    25 авг 06, 12:46    [3053208]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    DeColo®es
    Member

    Откуда: Москва
    Сообщений: 5499
    Блог
    GreenSunrise
    У вас другой подход к оповещению, судя по тому, что вы описали. Смысл в оповещении после bcp есть, если клиенты хотят получать уведомление о добавлении записей в таблицы. Если вам такое не нужно, то понятно, что и париться нечего :-)
    Ну, можно просто поднять типизированное событие: "добавились записи в такую-то табличку". Кто на это подписался - будет уведомлен. У решения автора есть 2 несомненных (связанных) плюса:
    1) решение не требует ничего, кроме уже имеющегося.
    То есть если ты подключаешься к серверу по ADO, других технологий применять не нужно.
    2) как следствие из 1-го. Сетевая инфраструктура не накладывает дополнительных ограничений на взаимодействие сервер-клиент. Дополнительных открытых портов, настрок шлюзов и т.д. - не нужно.

    Кстати, у нас система спроектирована так, что этот метод можно внедрить в качестве альтернативного транспортного протокола (сейчас только UDP поддерживается.). Надо будет подумать над этим... :)
    25 авг 06, 13:21    [3053447]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    DeColo®es
    Member

    Откуда: Москва
    Сообщений: 5499
    Блог
    Shocker.Pro
    Но UDP, насколько я знаю, не гарантирует доставку пакета.
    На это у нас есть автоответ клиента о получении и, в случае отсутствия ответа - повторная посылка. Если заданное количество попыток неудачные, сеанс переводится в состояние "подозрительный" и через некоторое время игнорируется системой вообще.
    25 авг 06, 13:25    [3053478]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    GreenSunrise
    Member

    Откуда:
    Сообщений: 12310
    Shocker.Pro
    GreenSunrise
    Мне в описанном решении не нравится необходимость стабильного канала, где связь железно не оборвется сама.


    Простите, а для работы с SQL-сервером разве не нужен постоянный канал? Или Вы работаете с отвязанным клиентом?

    Для работы с SQL сервером постоянный коннект не нужен. На чем и основывается работа веб-приложений, к примеру. Да и для клиентов другого типа вполне подходит.

    Shocker.Pro
    Но даже если так, постоянный канал для оповещений В ЛЮБОМ СЛУЧАЕ НУЖЕН, потому что с некоторыми клиентами SQL-сервер не сможет связаться по собственной инициативе, чтобы уведомить их о событии. А я просто использую стандартное соединение на стандартном порту.

    Спорный вопрос насчет "в любом случае". Вот в вашем - точно нужен.
    25 авг 06, 14:15    [3053855]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    GreenSunrise
    Member

    Откуда:
    Сообщений: 12310
    2Shocker.Pro: вы так болезненно вопросы и критику воспринимаете :-) Зачем тогда вообще на форум пишете?
    25 авг 06, 14:17    [3053864]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    SergSuper
    Member

    Откуда: SPb
    Сообщений: 5488
    GreenSunrise
    Спорный вопрос насчет "в любом случае". Вот в вашем - точно нужен.

    А как может сервер тогда послать оповещение если постоянного канала нет, а сам сервер иницировать конект не может?
    Мне чего-то в голову ничего не приходит
    25 авг 06, 14:28    [3053957]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Sergey Ch
    Member

    Откуда: Благовещенск
    Сообщений: 8870
    Много букв...

    В MS SQL Server 2005 это стандартная функция - при изменнии данных можно делать все что угодно - от посылки e-mail с уведомлением до text message на мобильный телефон клиента...
    25 авг 06, 14:40    [3054080]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Shocker.Pro
    Member

    Откуда: ->|<- :адуктО
    Сообщений: 21765
    GreenSunrise
    Спорный вопрос насчет "в любом случае". Вот в вашем - точно нужен.
    вы так болезненно вопросы и критику воспринимаете :-) Зачем тогда вообще на форум пишете?


    Да, я просто воспринял ваш ответ именно применительно к своему случаю, к которому он не подходит. Конечно, в локальных сетях можно использовать другие способы оповещения, но это получается опять связано с применением "внешних" средств.
    25 авг 06, 14:41    [3054100]     Ответить | Цитировать Сообщить модератору
     Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
    Shocker.Pro
    Member

    Откуда: ->|<- :адуктО
    Сообщений: 21765
    Sergey Ch
    MS SQL Server 2005 это стандартная функция - при изменнии данных можно делать все что угодно - от посылки e-mail с уведомлением до text message на мобильный телефон клиента...


    Простите, я сам еще не работал с SQL2005. E-mail можно послать и из SQL2000. Оно же может быть применено и для отсылки SMS - вполне стандартная функция.

    Скажите, как именно возбудить событие в клиенте стандартными средствами SQL2005 на ADO?
    25 авг 06, 14:45    [3054135]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7   вперед  Ctrl      все
    Все форумы / Microsoft SQL Server Ответить