У меня есть представление, которое выбирает строки из таблицы в другой базе данных. Я хотел бы предоставить избранный доступ к представлению, но не прямой доступ к базовой таблице. В представлении есть предложение where, ограничивающее количество строк.
Могу ли я предоставить выбор для представления, а не для базовой таблицы, или мне нужно переключиться на хранимую процедуру? Я бы предпочел не делать это последним способом.
Как вы заявляете в одном из своих комментариев, что рассматриваемая таблица находится в другой базе данных, применяется цепочка прав собственности. Я подозреваю, что где-то есть разрыв в цепочке - проверьте эту ссылку для получения полной информации.
GRANT SELECT ON [viewname] TO [user]
должен это сделать.
У меня также была эта проблема. Я использовал информацию из ссылки, упомянутую выше, и нашел быстрое решение. Если у вас есть другая схема, скажем test и создайте пользователя utest, владелец схемы test и среди просмотров в схеме test у вас есть представление vTestView на основе таблиц из схемы dbo, а при выборе из него вы получите ошибку, упомянутую выше, - нет доступа к базовым объектам. Мне было достаточно выполнить оператор
ALTER AUTHORIZATION ON test.vTestView TO dbo;
что означает, что я изменяю собственность vTextView из схемы, к которой он принадлежит (test), к пользователю базы данных dbo, владелец схемы ДБО. После этого без каких-либо других разрешений пользователь utest сможет получить доступ к данным из test.vTestView
Вы можете предоставить разрешения для представления, а не для базовой таблицы. Это одна из причин, по которой людям нравится использовать представления.
Посмотрите здесь: Разрешения объекта GRANT (Transact-SQL)
Я попробовал это в одной из моих баз данных.
Чтобы заставить его работать, пользователь должен был быть добавлен в базу данных, где хранятся фактические данные. Права не нужны, просто доступ.
Вы считали сохранение представления в базе данных, на которую ссылается? Повторное использование и все, если бы его преимущества могли следовать.
Просто материализованный взгляд, тогда вам не нужно беспокоиться обо всех других факторах. Это будет работать только в том случае, если пространство и время обновления не являются большой проблемой.. материализованные представления довольно крутые.
У меня была аналогичная проблема, когда я получал то же сообщение об ошибке для пользователя. Я чувствую, что, поделившись своей ошибкой, я могу решить проблему, ответить на вопрос и не дать другим совершить ту же ошибку.
Я хотел, чтобы пользователь имел доступ к 4 определенным представлениям, не имея доступа к их базовым таблицам (или что-то еще в БД, если на то пошло).
Первоначально я дал им членство в роли базы данных "db_denydatareader", думая, что это помешает им выбрать что-либо из любой таблицы или представления (что было сделано, как я думал), хотя я тогда предоставил "выбор" на этих 4 предполагая, что он будет работать так, как я предполагал, - это не так.
Правильный способ сделать это - просто not предоставить им роль db_datareader и просто предоставить "select" для элементов, которые вы хотите, чтобы пользователь мог получить доступ. Результаты вышеизложенного заключались в том, что пользователь смог получить абсолютно ничего за пределами этих 4 представлений - таблицы, на которых эти области обзора на основе данных также недоступны для этого пользователя.
У меня была эта проблема. Похоже, что хотя разрешение "View1" как часть схемы "schema1" должно быть предоставлено владельцем "dbo", если View1 использует dbo.table1.
Если не используется схема, которая не является частью dbo, эта проблема может не проявиться, и будет работать регулярное решение "Grant Select to user".