Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Как отследить дополнительные сеансы при асинхронном выполнении хранимых процедур через ADO  [new]
HandleX
Member

Откуда:
Сообщений: 14
Я новичёк на этом форуме, возможно такое уже было, однако в поиске не нашёл.

Итак, проблема.
Клиентская программа использует ADO для доступа к MS SQL серверу по TCP/IP.
Встроенный в MS SQL механизм аутентификации используется только для создания объекта ADO Connection, на сервере реализована своя процедура логина и контроля доступа, причём полученный идентификатор пользователя сохраняется при помощи SET CONTEXT_INFO в контексте сеанса. Соответственно, все процедуры, которые проверяют контроль доступа, обращаются к полю context_info системной таблицы sysprocesses.

И всё бы хорошо, если бы не один подводный камень, связанный с асинхронным исполнением процедур (объект ADODB_Command с соотв. опциями) на клиентской стороне. ADO, не мудрствуя лукаво, САМО ОТКРЫВАЕТ ещё один сеанс (грубо говоря TCP подключение к серверу, это видно если посмотреть netstat), если при попытке асинхронного выполнения первоначальный сеанс чем-то занят (а ведь для того и была создана асинхронная команда, чтобы на фоне что-то делала). Соответственно, @@SPID на сервере другой, и context_info пустой. Боле того, ADO дропает ненужные ему сеансы тоже сам и причём дропает более старые в первую очередь. Т.е. в конце концов context_info слетает и у обычных синхронных объектов ADO_Command.

Задача: синхронизировать context_info между внутренними сеансами ADO. Событие willConnect у объекта ADODB_Connection не возникает при вышеуказанном раскладе.

Заранее всем огромное спасибо за советы!
12 авг 08, 13:23    [6056486]     Ответить | Цитировать Сообщить модератору
 Re: Как отследить дополнительные сеансы при асинхронном выполнении хранимых процедур через  [new]
ГСА
Guest
Либо не используйте CONTEXT_INFO, либо открывайте соединения ручками и выполняйте запросы допустим не через ado, а в потоках.
12 авг 08, 13:32    [6056556]     Ответить | Цитировать Сообщить модератору
 Re: Как отследить дополнительные сеансы при асинхронном выполнении хранимых процедур через  [new]
HandleX
Member

Откуда:
Сообщений: 14
ГСА
Либо не используйте CONTEXT_INFO, либо открывайте соединения ручками и выполняйте запросы допустим не через ado, а в потоках.

Замечательно. Основная идея использования CONTEXT_INFO была в том, чтобы не передавать идентификатор пользователя при КАЖДОМ вызове любой защищённой своим велосипедным ACL процедуры, CONTEXT_INFO подходил для этого идеально и не использовать его сложно.

Нда, жаль, видимо прийдётся для каждой асинхронной команды заюзать отдельный ADODB_Connection.

Подождём, может ещё гуру к топику подтянутся... :-)
12 авг 08, 14:12    [6056859]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Как отследить дополнительные сеансы при асинхронном выполнении хранимых процедур через ADO  [new]
programmer-v
Member

Откуда: Калининград
Сообщений: 1
А где хранится информация по пользователям?
и их правам доступа?
если это пользователи заведенные как пользователи ms-sql сервера то можно идентифицироваться по ID пользователя
функцией USER_ID() или другими
Если это свои таблицы то при коннекте можно получить свой ID в системе и приписать его в своей таблице
рядом с именем пользователя и дальше опять идентифицировать себя системными функциями в начале ХП сравнивая ID
23 авг 11, 14:43    [11164429]     Ответить | Цитировать Сообщить модератору
 Re: Как отследить дополнительные сеансы при асинхронном выполнении хранимых процедур через ADO  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2423
programmer-v
А где хранится информация по пользователям?
и их правам доступа?
если это пользователи заведенные как пользователи ms-sql сервера то можно идентифицироваться по ID пользователя
функцией USER_ID() или другими
Если это свои таблицы то при коннекте можно получить свой ID в системе и приписать его в своей таблице
рядом с именем пользователя и дальше опять идентифицировать себя системными функциями в начале ХП сравнивая ID


Спасибо что просветили нас неразумных, а то, ведь мы все эти 3 года мучались данным вопросом, даже не спали по ночам:)
23 авг 11, 14:51    [11164552]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить