Добавил роль SomeRole*, затем добавил себя к этой роли, затем спросил Is_Member('SomeRole') - сервер сказал что нет... в чем загвоздка?.. принадлежность к группе пользователей windows NT тоже не определяется (ты говорит member 'dbo', а не 'SomeDomain\SomeAdministrators')... даже обидно как-то стало...

* любое совпадение имен считать чистой случайностью...

surely...

ну у меня на простых примерчиках-то она тоже отрабатывается неплохо... меня ж интересует разграничение - w2k отвечает за безопасность (списки групп пользователей), а хранимые процедуры справляются о принадлежности пользователя к той или иной группе (чтобы выдавать разные наборы данных для разных групп)... причем все входят не под sql логином - а под w2k через HTTP (suser_sname() срабатывает без претензий (это на случай если кто начнет меня учить virtual directory настраивать))... вот тут-то и начинается настоящее веселье... а существуют какие-либо более вероятные причины сбоев в работе этой ё<beep> функции кроме особенностей строения тела, последствий черепно-мозговых травм в детстве, фаз луны, грехов в предыдущих жизнях и иже с ними?...

P.S. Шаманский бубен от Microsoft(r) просьба не предлагать

ха-ха... "обычно" - слово-то какое... обычно в фонтанах да еще в одежде тоже не купаются - а зря... я ж не желаю просто отвергать или разрешать доступ к stored proc... она (sp) должна выдавать разные наборы данных для пользователей разных групп (несомненно из числа имеющих к ней доступ - тут я никакого велосипеда изобретать не собираюсь - стандартная безопасность NT)... данные выдаются в формате XML - потом пребразуются через XSL в XHTML... в результате, например, пользователь не имеющий права изменять данные вообще не увидит ссылку/кнопку "Изменить/удалить" (вместо ОБЫЧНОЙ реакции системы - ACCESS DENIED) или начальник отдела просто увидит список только "своих" сотрудников и т.д. и т.п. Получится своебразная реализация системы безопасности не на уровне объекта базы данных или даже колонок в таблице, а на уровне самих данных. Причем безо всяких особых усилий... не надо ни писать отдельную sp для каждой группы, ни сопровождать в самой базе таблицу принадлежности юзеров к тому или иному предприятию, отделу, группе и т.д. Администратор переведет из разряда User в AdvancedUser - получай новый уровень отчета, перевели из отдела в отдел - получи список своих ковокеров*... sp может даже и поздравить человека с повышением или переводом... Всё круто и клёво.. кстати - с функцией я уже разобрался... она только "dbo" так не любит (и то есть подозрение что только меня... может, действительно, меньше в фонтанах надо купаться? ... рядовых пользователей она признает нормально - проверено на людях...

* ковокер - американизм от co-worker...

это любому ёжику понятно... мне не понравилось только то что при этом меня не считают, допустим, бухгалтером, несмотря на занесение в соответствующую группу или роль...