回答:
SQL Server 2008以降:
/* CREATE A NEW ROLE */
CREATE ROLE db_executor
/* GRANT EXECUTE TO THE ROLE */
GRANT EXECUTE TO db_executor
(ロールではなく)ユーザーのみの場合:
USE [DBName]
GO
GRANT EXECUTE TO [user]
user
が角括弧の中になければならないかもしれないことに注意する価値があると思います。これは、少なくとも一部には、ユーザーにドメインがアタッチされていた(つまり、\文字が含まれていた)ため、私のユースケースに当てはまりました。編集:エスケープされていないスラッシュ文字を修正
SQL Server 2005では、データベースの実行権限をデータベースの原則に付与する機能が導入されました。
GRANT EXECUTE TO [MyDomain\MyUser]
これにより、すべてのスキーマのすべてのストアドプロシージャが暗黙的に含まれるデータベーススコープで権限が付与されます。つまり、ストアドプロシージャごとにアクセス許可を明示的に付与する必要はありません。
さらに細かくしたい場合は、スキーマの実行権限を付与して制限することもできます。
GRANT EXECUTE ON SCHEMA ::dbo TO [MyDomain\MyUser]
上記の回答に加えて、以下を追加します。
代わりにこれをロールに付与し、そのロールをユーザーに割り当てることができます。をmyAppRights
介してロールを作成したとします
CREATE ROLE [myAppRights]
次に、実行権限を与えることができます
GRANT EXECUTE TO [myAppRights]
その役割に。
または、スキーマレベルで実行する場合:
GRANT EXECUTE ON SCHEMA ::dbo TO [myAppRights]
また、機能します(この例では、ロールmyAppRights
はdbo
後でスキーマのすべての要素に対する実行権限を持ちます)。
このように、一度行うだけで、後で変更する必要がある場合に、関連するすべてのアプリケーション権限をユーザーに簡単に割り当てたり取り消したりできます。特に、より複雑なアクセスプロファイルを作成する場合に便利です。
注:スキーマにロールを付与すると、後で作成する要素にも影響します。これは、意図した設計によっては有益であるかどうかにかかわらず、留意してください。
[役割]に実行を許可
これは確かに役立ちます