DBCC CHECKIDENT для временной ошибки выдачи разрешений для неверного пользователя

Question

Я вошел в базу данных SQL Server 2005 как пользователь не-sa, bhk, который является членом только роли public. Следующий код пытается выполнить в хранимой процедуре, вызванной пользователем 'BHK'. Эта строка кода ...

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

вызывает эту ошибку ...

Пользователь 'гость' не имеет разрешения запустить DBCC CHECKIDENT для объекта
'# Table1__00000000007F'.

Мне известны разрешения, необходимые для запуска DBCC CHECKIDENT ...
Вызывающий должен владеть таблицей или быть членом фиксированной серверной роли sysadmin, фиксированной роли базы данных db_owner или фиксированной роли базы данных db_ddladmin.

Итак, у меня два вопроса:

1. Так как 'bhk' вызывает сохраненный процедура, которая создает временный столик, не должен быть «бхк» владельцем и будет разрешено запускать DBCC CHECKIDENT
2. Почему ошибка сообщение вернуть этого пользователя "гость" не имеет разрешения? Насколько я знаю, я не Вы вошли как 'гость'.

Любая помощь будет принята с благодарностью.

Answer 1

Вот альтернативное решение, которое может сработать, если вам нужно заново посеять с порядковым номером больше 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 для вашей временной таблицы, чтобы позволить вам добавить строку с явным идентификатором. Затем вы можете удалить эту строку, но дальнейшие вставки должны начинаться с последнего порядкового номера.

Answer 2

Вы можете сделать это, полностью квалифицировав таблицу tempdb.

DBCC CHECKIDENT([tempdb..#Table1], RESEED, @SequenceNumber) WITH NO_INFOMSGS

Answer 3

Вы писали:

"Звонящий должен владеть столом или быть член фиксированного сервера sysadmin роль, db_owner исправлен. "

Итак (если это не ошибка), согласно безупречной логике лейтенанта Коломбо, каждое из предположений должно быть ложным. Это означает, что вызывающий не владеет таблицей, , даже если он ее создал.

На самом деле, кажется, что все объекты, созданные в tempd , по умолчанию принадлежат dbo . Вы можете проверить это, если выполните следующие действия в Query Analyzer:

1. Подключитесь к вашей базе данных , используя пользователя с низким разрешением.
2. Выполнить: CREATE TABLE #NotMyTable (TestID int identity)
3. Подключение к tempdb того же SQL Server , что и dbo
4. Выполнить: SELECT user_name(uid) FROM sysobjects WHERE name LIKE '#NotMyTable%'

Вы увидите, что dbo является владельцем временной таблицы.

Итак, что может быть решением?

(Предисловие: Мне не нравятся такие манипуляции, но интеллектуальный стимул ведет меня ...; -) )

Таким образом, вы можете написать другую хранимую процедуру, которая обновляет UID в системных объектах базы данных tempdb до значения вашего пользователя ( shiver! ). Я проверял это только в Query Analyzer. После обновления я смог выполнить вашу команду DBCC CHECKIDENT.

Answer 4

Я только что столкнулся с этим. Я пришел к ответу, чтобы дать соответствующей учетной записи разрешения в базе данных tempdb, где, по-видимому, были созданы эти таблицы.

Answer 5

Альтернативным решением для выполнения команд TRUNCATE и CHECKIDENT было бы просто удалить и заново создать временную таблицу. Э.Г.

DROP TABLE #Table1

CREATE TABLE #Table1
(
   ....
)

Возможно, это не самое эффективное решение.