sql-server-2005 - reiniciar - reseed identity sql server 2012

DBCC CHECKIDENT en una tabla temporal arrojando errores de permisos para usuarios incorrectos

Question

He iniciado sesión en una base de datos de SQL Server 2005 como usuario no sa, ''bhk'', que es miembro de la función de servidor ''público'' solamente. El siguiente código intenta ejecutarse dentro de un procedimiento almacenado llamado por el usuario ''bhk''. Esta línea de código ...

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

causa este error ...

Usuario ''invitado'' no tiene permiso para ejecutar DBCC CHECKIDENT para el objeto
''# Table1__00000000007F''.

Soy consciente de los permisos necesarios para ejecutar DBCC CHECKIDENT ...
La persona que llama debe ser propietaria de la tabla o ser miembro de la función de servidor fijo sysadmin, la función de base de datos fija db_owner o la función de base de datos fija db_ddladmin.

Entonces tengo dos preguntas:

1. Dado que ''bhk'' llama a un procedimiento almacenado que crea una tabla temporal, ¿no debería ser ''bhk'' el propietario y se le debe permitir ejecutar DBCC CHECKIDENT?
2. ¿Por qué el mensaje de error devuelve que el usuario ''invitado'' no tiene permiso? Que yo sepa, no estoy conectado como ''invitado''.

Cualquier ayuda sería muy apreciada.

Answer 1

Aquí hay una solución alternativa, que puede funcionar si necesita reiniciar con un número de secuencia de más de 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

Lo que está haciendo es establecer IDENTITY_INSERT en su tabla temporal, para permitirle agregar una fila con una ID explícita. A continuación, puede eliminar esta fila, pero las inserciones adicionales deben comenzar desde el último número de secuencia.

Answer 2

Tu escribiste:

"La persona que llama debe ser propietaria de la mesa, o ser un miembro de la función de servidor fijo sysadmin, el propietario de db está arreglado".

Entonces (si no es un error), de acuerdo con la impecable lógica del Teniente Columbo , cada una de las premisas debe ser falsa. Eso significa que la persona que llama no posee la mesa, incluso si la creó.

De hecho, parece que todos los objetos creados en tempd son propiedad de dbo por defecto. Puede examinarlo, si lo sigue en el Analizador de consultas:

1. Conéctese a su base de datos usando el usuario de bajo permiso.
2. Ejecutar: CREATE TABLE #NotMyTable (TestID int identity)
3. Conéctese a tempdb del mismo servidor SQL como dbo
4. Ejecutar: SELECT user_name(uid) FROM sysobjects WHERE name LIKE ''#NotMyTable%''

Verá que dbo es el propietario de la tabla temporal.

Entonces, ¿qué podría ser una solución?

(Prólogo: No me gusta ese tipo de manipulación, pero el estímulo intelectual me está impulsando ... ;-) )

Entonces, podría escribir otro procedimiento almacenado que actualice el UID en sysobjects del tempdb al valor de su usuario ( ¡escalofrío! ). Lo probé solo en el Analizador de consultas. Después de la Actualización, podría ejecutar su comando DBCC CHECKIDENT.

Answer 3

Una solución alternativa para hacer los comandos TRUNCATE y CHECKIDENT sería simplemente soltar y volver a crear su tabla temporal. P.ej

DROP TABLE #Table1
CREATE TABLE #Table1
(
....
)

Sin embargo, esta puede no ser la solución más eficiente.

Answer 4

Puede lograr esto calificando completamente la tabla tempdb.

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

Answer 5

Me encontré con esto. La respuesta a la que llegué fue darle a la cuenta relevante los permisos en la base de datos tempdb donde, aparentemente, se crearon estas tablas.