Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Visual Basic [игнор отключен] [закрыт для гостей] / Неплохая идея использования возможностей ADO - вполне достойная FAQ по ADO / 1 сообщений из 1, страница 1 из 1
25.08.2006, 21:09
    #33944305
sysadm2000
sysadm2000
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Неплохая идея использования возможностей ADO - вполне достойная FAQ по ADO
Код: plaintext
хорошо бы код этого фрагмента.
Ну текста тут как такового нет - смотри рисунок. Здесь выдвинута идея использования некоторых стандартных возможностей ADODB.Connection для оповещения об изменения в рекордсетах.

К справедливой критике этого подхода, указанной автором:
Код: plaintext
1.
2.
3.
процесс, в результате работы которого должно возникнуть оповещение, должен иметь права процессадмина чтобы выполнить команду KILL, права на которую не могут быть делегированы. Впрочем, процессадмины имеют право только на KILL и на назначение этих прав другим пользователям, что опять же ограничивается командой KILL.
KILL не может быть использована внутри транзакции (в частности - в триггере). Если есть необходимость использования оповещения из триггера, можно запустить KILL отдельным процессом через sp_start_job.
если по каким-то причинам клиент не получит хотя бы одного события ExecuteComplete, то он перестанет следить за событиями сервера, так как процедура ожидания не запустится заново. В частности, это может произойти у программиста при работе с отладчиком, когда событие возникло, а клиентское приложение было в режиме паузы. Ну и на ADO стопроцентной надежды нет, в асинхронном режиме работает из рук вон плохо. Я сделал так - на имеющийся у меня ежеминутный (для других целей) таймер повесил проверку, если вдруг объект Command не находится в режиме adStateExecuting, то запускается процедура инициализации соединения.
я, наверное, добавлю еще несколько своих соображений:

1. Специфика базы MASTER, возможная зависимость ее от версии SQL - от этого ненадежность прямой работы в ней.
2. Невозможность организации прокси-сервера (как в случае оповещения по TCP/IP), те SQL должен напрямую иметь ВНЕШНИЙ IP. Комментарии излишни.
3. Оповещение по TCP/IP поддерживает ПУЛЬСАЦИЮ, (фрагмент кода в самом низу рисунка). Здесь конечно никакой пульсации нет и удаленные соединения через TCP/IP сеть будут рваться.
4. Еще одна причина неконкурентности такого оповещения относительно оповещений по TPC/IP - оповещение по TCP/IP передает произвольные ДАННЫЕ от сервера к клиенту, ну например в каком именно рекордсете произошло событие. Здесь, конечно, обьект ADODB.Connection таких возможностей не предоставляет.
5.
Код: plaintext
плохо масштабируемое решение
Я наверное присоединюсь к этому мнению, ибо вся логика развития доступа к данным построена НА СКОРЕЙШЕМ ОСВОБОЖДЕНИИ клиентом SQL-сервера. Для чего вообще в Микрософте делали ADO.NET?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Visual Basic [игнор отключен] [закрыт для гостей] / Неплохая идея использования возможностей ADO - вполне достойная FAQ по ADO / 1 сообщений из 1, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 400ms
Закрыть
start [/forum/topic.php?fid=60&mobile=1&tid=2165397]:
 0ms
get settings:
 6ms
get forum list:
 10ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 151ms
get topic data:
 6ms
get forum data:
 1ms
get page messages:
 20ms
get tp. blocked users:
 1ms
others: 201ms
total:  400ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]