ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Visual Basic [игнор отключен] [закрыт для гостей] / Неплохая идея использования возможностей ADO - вполне достойная FAQ по ADO
1 сообщений из 1, страница 1 из 1
Неплохая идея использования возможностей ADO - вполне достойная FAQ по ADO
    #33944305
sysadm2000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysadm2000
Участник
Код: 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
25.08.2006, 21:09
| Ответить | Цитировать | Написать  
1 сообщений из 1, страница 1 из 1
Форумы / Visual Basic [игнор отключен] [закрыт для гостей] / Неплохая идея использования возможностей ADO - вполне достойная FAQ по ADO
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=60&fpage=268&tid=2165397]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 49ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 30ms
get tp. blocked users:
 2ms
others: 211ms
total:  334ms
созд. / загр.: 334ms
x
x
Закрыть


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