Уважаемые! Есть проблема.
Согласно документации Microsoft, если на VIEW дать разрешения на INSERT, UPDATE и DELETE, то на саму таблицу на которой построен VIEW разрешения можно не давать. Данное утверждение правильно, если делать это через Query Analyzer или через ODBC каким-нибудь клиентом. Но это не срабатывает, если это делать из MS Access (.ADP) или, хотя бы, из SQL Server Enterprise Mansger. При этом возникает ошибка, где говорится, что не даны права на саму таблицу.

Все это верно, но при использовании динамического SQL и дальнейшего его вызова, типа exec('sql выражение') все равно требется права на таблицу. Допустим я как dbo создал таблицу Т1, затем создал VW1 на основе Т1. Даю все права на VW1 и никаких прав на Т1. Затем я делаю комманду типа exec('update VW1 set поле1=1') и получаю сообщение, что нет прав на SELECT на Т1. Это происходит только при подключении через OLE DB. При подключении через ODBC такие вещи проходят и работают.

>>exec ВСЕГДА выполняется с правами пользователя, его запустившего, а не владельца процедуры.

Нет!!!! Есть исключение - это динамический SQL, ну еще есть команды и системные процедуры, которые могут исполнять только разные администраторы, например SQL-команда SETUSER. Если не верите, то сами попробуйте. Создайте таблицу, заполните ее некоторыми данными, затем создайте процедуру где будет команда exec('select * from таблица') и получите результат!!!!

Так что, нет ни у кого дельного совета? Можно долго рассуждать про права, пользователей, но, как говориться, воз и ныне там. Проблема-то возникла по следующей причине. Есть некая таблица на которой построен вид, который ограничивает набор записей. Есть форма у которой источником данных служит этот вид. Пользователь должен изменять данные в форме, вносить новые и т.д., но только в рамках данного вида. Вообще-то тривиальная задача, но при этом получается, что нужно давать разрешение на базовую таблицу, что является пробелом и очень серьезным пробелом в защите данных. Я пока данную проблему решаю по своему, но этот способ тоже имеет недостатки. Заключается он в том, чтобы сделать группу в которую входят пользователи и назначить группе права на SELECT на вид. Затем сделать Application Role, которая входит в стандартную роль тем самым AR дается права на select на вид. Дополнительно AR дается все права на базовую таблицу. Затем можно залогонится под AR используя sp_setapprole. Все!!! Самой таблицы в Access не видно, а виден только вид и с ним проходят операции delete,insert и update.

Но данный метод имеет недостатки. ЕСТЬ ЛИ У КОГО АЛЬТЕРНАТИВА???? Только, пожалуйста, не нужно предлагать перейти на другой язык и т.п. Есть много програмных наработок на Access и переходить на другую платформу равносильно пожару.

>>Попробуй создать этот VIEW с опцией 'WITH VIEW_METADATA'.

У меня MS SQL Server 7.0, там вроде-бы нет этой опции.