2009-04-28 17 views
7

Tengo la siguiente configuración:Problema con SQL Server "EJECUTAR" TAL

Hay un servidor de base de datos SQL con varias tablas que tienen disparadores establecidos en ellos (que recogen datos de la historia). Estos activadores son procedimientos almacenados de CLR con EXECUTE AS 'HistoryUser'. El usuario HistoryUser es un usuario simple en la base de datos sin un inicio de sesión. Tiene permisos suficientes para leer en todas las tablas y escribir en la tabla de historial.

Cuando hago una copia de seguridad de la base de datos y luego la restauro a otra máquina (máquina virtual en este caso, pero no importa), los disparadores ya no funcionan. De hecho, ya no funciona la suplantación para el usuario. Incluso una simple declaración como este

exec ('select 3') as user='HistoryUser' 

produce un error:

Cannot execute as the database principal because the principal "HistoryUser" does not exist, this type of principal cannot be impersonated, or you do not have permission.

I read in MSDN que esto puede ocurrir si el dueño del DB es un usuario de dominio, pero no lo es. E incluso si lo cambio a cualquier otra cosa (su solución recomendada), este problema persiste.

Si creo otro usuario sin iniciar sesión, puedo usarlo para la suplantación muy bien. Es decir, esto funciona muy bien:

create user TestUser without login 
go 
exec ('select 3') as user='TestUser' 

no quiero recrear todos los factores desencadenantes, por lo que ¿hay alguna manera de cómo puedo hacer el trabajo existente HistoryUser?

Bump: Lo sentimos, pero esto es algo urgente ...

Respuesta

4

Qué cuenta de usuario no ejecutar el gatillo como.

Deberá otorgarle a ese usuario los privilegios de IMPERSONATE para el Usuario Historial de la cuenta de usuario.

GRANT IMPERSONATE ON USER:: YourUser TO HistoryUser 

Más detalles aquí

http://msdn.microsoft.com/en-us/library/ms181362.aspx

+0

Nop, no ayuda. –

4

problemas de este tipo que se presentan después de mover una base de datos de una máquina a otra SID implican generalmente no coincidentes de, aunque no estoy seguro de si o cómo se aplica a Tu caso. Intente eliminar y volver a crear el usuario de la base de datos, asegurándose de restablecer sus permisos a esas tablas.

+0

Ese es el punto: este usuario nunca tuvo un inicio de sesión. ¿Qué SIDs? Y, como dije en la pregunta anterior, prefiero no recrear al usuario, porque entonces también tengo que recrear un montón de factores desencadenantes. –

+0

Esto funcionó para mí. Tuvimos que migrar la base de datos desde otro servidor y nos encontramos con este problema. – ahwm

3

Es un "usuario huérfano". No funcionará La documentación dice esto claro. :-( Corrige el estado de "usuario huérfano" y volverá a funcionar

+2

¿Qué documentación? ¿Podría proporcionar un enlace? Gracias – doza

5

Detecta los usuarios huérfanos, luego resuelve mediante el enlace a un inicio de sesión.

detectar: ​​

USO <database_name>;
GO;
sp_change_users_login @ Action = ' Informe ';
GO;

RESOLVE:
El siguiente comando vuelve a vincular la cuenta de inicio de sesión del servidor especificado por <login_name> con el usuario base de datos especificada por <DATABASE_USER>:

USO <database_name>;
GO
sp_change_users_login @ Action = ' update_one ',
@ UserNamePattern = ' <DATABASE_USER> ',
@ LoginName = ' <login_name> ';
GO

https://msdn.microsoft.com/en-us/library/ms175475.aspx

Cuestiones relacionadas