8

'public' サーバー ロールのみのメンバーである非 sa ユーザー 'bhk' として SQL Server 2005 データベースにログインしています。次のコードは、ユーザー 'bhk' によって呼び出されたストアド プロシージャ内で実行を試みます。このコード行...

TRUNCATE TABLE #Table1
DBCC CHECKIDENT('#Table1', RESEED, @SequenceNumber) WITH NO_INFOMSGS

このエラーの原因...


ユーザー 'guest' には、オブジェクト'#Table1__00000000007F'に対して DBCC CHECKIDENT を実行する権限がありません。

DBCC CHECKIDENT を実行するために必要なアクセス許可を認識しています...
呼び出し元は、テーブルを所有しているか、sysadmin 固定サーバー ロール、db_owner 固定データベース ロール、または db_ddladmin 固定データベース ロールのメンバーである必要があります。

だから私は2つの質問があります：

  1. 'bhk' は一時テーブルを作成するストアド プロシージャを呼び出しているため、'bhk' は所有者であり、DBCC CHECKIDENT の実行を許可されるべきではありませんか?
  2. ユーザー 'guest' にアクセス許可がないというエラー メッセージが返されるのはなぜですか? 私の知る限り、「ゲスト」としてログインしていません。

どんな助けでも大歓迎です。

4

5 に答える 5

8

1 以上のシーケンス番号で再シードする必要がある場合に有効な代替ソリューションを次に示します。

TRUNCATE #Table1

SET IDENTITY_INSERT #Table1 ON

INSERT INTO #Table1 (TableID) -- This is your primary key field
VALUES (@SequenceNumber - 1)

SET IDENTITY_INSERT #Table1 OFF

DELETE FROM #Table1

これは、一時テーブルに IDENTITY_INSERT を設定して、明示的な ID を持つ行を追加できるようにすることです。その後、この行を削除できますが、それ以降の挿入は最後のシーケンス番号から開始する必要があります。

于 2008-10-13T15:39:05.857 に答える
4

あなたが書いた：

「呼び出し元は、テーブルを所有しているか、sysadmin 固定サーバー ロールのメンバーである必要があります。db_owner が固定されています。」

したがって、(バグでなければ)、コロンボ中尉の非の打ちどころのない論理によれば、それぞれの前提は誤りであるに違いありません。つまり、呼び出し元はテーブルを作成したとしても、そのテーブルを所有していません。

実際、tempd で作成されたすべてのオブジェクトは、デフォルトで dbo によって所有されているようです。Query Analyzer で次の操作を行うと、それを調べることができます。

  1. 権限の低いユーザーを使用してデータベースに接続します。
  2. 実行する：CREATE TABLE #NotMyTable (TestID int identity)
  3. dboと同じ SQL Server のtempdbに接続します。
  4. 実行する：SELECT user_name(uid) FROM sysobjects WHERE name LIKE '#NotMyTable%'

dbo が一時テーブルの所有者であることがわかります。

それで、解決策は何ですか？

(序文:私はそのような操作は好きではありませんが、知的刺激が私を駆り立てています. ;-) )

したがって、tempdb の sysobjects の UID をユーザーの値 ( shiver! ) に更新する別のストアド プロシージャを作成できます。Query Analyzer でのみテストしました。更新後、DBCC CHECKIDENT コマンドを実行できました。

于 2008-10-11T15:16:26.543 に答える
3

これは、tempdb テーブルを完全に修飾することで実現できます。 

DBCC CHECKIDENT([tempdb..#Table1], RESEED, @SequenceNumber) WITH NO_INFOMSGS
于 2011-02-08T17:00:03.267 に答える
1

TRUNCATE および CHECKIDENT コマンドを実行する代わりの解決策は、単純に一時テーブルを削除して再作成することです。例えば

DROP TABLE #Table1

CREATE TABLE #Table1
(
   ....
)

ただし、これは最も効率的なソリューションではない可能性があります。

于 2008-10-13T09:07:27.690 に答える
1

私はちょうどこれに遭遇しました。私がたどり着いた答えは、明らかに、これらのテーブルが作成された tempdb データベースで、関連するアカウントにアクセス許可を与えることでした。

于 2012-04-30T15:23:47.827 に答える