これが可能な最も簡単な再現ケースです。
このエラーメッセージで失敗します。
メッセージテキスト:
TITLE:Microsoft SQL Server Management Studio
このリクエストのデータを取得できませんでした。 (Microsoft.SqlServer.Management.Sdk.Sfc)
ヘルプが必要な場合は、次をクリックしてください リンク
追加情報:
Transact-SQLステートメントまたはバッチの実行中に例外が発生しました。 (Microsoft.SqlServer.ConnectionInfo)
オブジェクト 'extended_properties'、データベースmssqlsystemresource '、スキーマ' sys 'に対するSELECT権限が拒否されました。 (Microsoft SQL Server、エラー:229)
ヘルプが必要な場合は、次をクリックしてください リンク
このユーザーは、テーブルとテーブル内のレコードにアクセスできます。ただし、ユーザーはオブジェクトエクスプローラーのテーブルのリストにアクセスできません。
SELECT USER_NAME() AS CurrentUser, col1
FROM dbo.TestTable
CurrentUser col1
----------- ----
robg_test 1000
私が見つけた唯一の回避策は、ユーザーに必要以上の特権(db_datareaderなど)を与えることです。
このユーザーがオブジェクトエクスプローラーでテーブルリストを開くために必要なminimum特権とは何ですか?
ユーザーにdboスキーマに対するさまざまな権限を付与しようとしましたが、それは役に立ちませんでした。
また、問題を説明するためにSQLユーザーを使用していることにも注意してください。元の問題はADユーザーにありました。
ここ は、serverfaultで比較的類似した質問です。
SET NOCOUNT ON
USE master
GO
IF EXISTS (SELECT * FROM sys.server_principals WHERE name = N'robg_test')
DROP LOGIN [robg_test]
GO
CREATE LOGIN [robg_test]
WITH
PASSWORD = N'CLK63!!black',
DEFAULT_DATABASE = [RGTest],
DEFAULT_LANGUAGE = [us_english],
CHECK_EXPIRATION = OFF,
CHECK_POLICY = ON
GO
IF EXISTS (SELECT * FROM sys.databases WHERE name = 'RGTest')
DROP DATABASE [RGTest]
GO
CREATE DATABASE [RGTest]
GO
USE [RGTest]
GO
CREATE USER [robg_test] FOR LOGIN [robg_test] WITH DEFAULT_SCHEMA = [dbo]
GO
CREATE TABLE dbo.TestTable (col1 int)
GO
GRANT SELECT ON dbo.TestTable TO [robg_test]
GO
INSERT INTO dbo.TestTable VALUES (1000)
GO
チェックしていないことを確認してくださいdb_denydatareader
DBロール。そのチェックを削除することにより、それは私のために働いた。
私は同様の問題を抱えており、そのユーザーの2つのロールdb_denydatareaderとdb_denydatawriterを削除して、他のロールを追加することで解決しました。私はSQL管理スタジオを使用しました。
SSMSは fn_listextendedproperty
を使用してテーブルの拡張プロパティを取得しようとします。 [〜#〜] msdn [〜#〜] によると、テーブルの拡張プロパティを表示するために必要な権限は次のとおりです。
テーブルOBJECTに対するALTER
ログインテストでは、テストテーブルの所有者としてこの権限が必要です(所有者ですよね?)。ただし、テーブルに対する権限がない場合でも、拡張プロパティのクエリは、アクセス拒否ではなく空の結果セットを返す必要があります。リソースデータベースのsysオブジェクトでアクセス拒否エラーが発生するという事実は、システムリソースデータベース(mssqlsystemresource)のコード署名が壊れていることを示しています。マスターから「##」証明書を削除しましたか?リソースデータベースのオブジェクトを手動で変更しましたか?
とにかく、現時点ではインスタンスが壊れているように見えるので、一貫性のある状態に戻す方法について製品サポートに連絡することをお勧めします。
同様の問題がありました。ユーザーをパブリックロールに追加することで解決しました。しかし、それを実行したくない場合は、ユーザーにビューsys.extended-properties(アクセスしようとしているデータベース内のシステムビュー内)へのアクセス許可を与えることで解決できることもわかりました。
「SQLサーバーデータベースをアカウントで作成することにより、そのアカウントは所有者であり、必要なすべてのアクセス権を持ちます」
権限をさらに強化する必要はありません。
このアプローチにより、このスレッドのように見えるアクセスエラーが削除されました。 SSMSとVisual Studio(EF)で、Windows認証を使用し、管理者アカウントでSQLサーバーDBを作成したときに、アクセスエラーが発生しました。
私のための実用的な解決策は:
SSMS>管理者として開始、SQLサーバーログオン:Windows認証あり-SQLサーバーデータベースを作成しない-アカウントに「マスター」に対する「データベースの作成」権限を与える
次に、そのアカウント(マスターに対する 'dbの作成'権限を持つ)でSSMSログオン-(空の)データベースを作成します
(VISUAL STUDIO xtra:次に、Visual Studioで、そのアカウントでSQLサーバーに接続し、LocalDB(ソース)とSQLサーバーdb(ターゲット)の間でスキーマを比較します。うまく機能します。ターゲットdbはスキーマとデータコンテンツを取得します)