58

Tengo una pregunta acerca User-Defined Table Types en SQL Server 2008.El permiso EXECUTE se deniega en los tipos de tabla definidos por el usuario?

Por la necesidad de una de las aplicaciones ASP.NET definimos nuestra propia mesa de tipo mediante SQL Server 2008 para usarlos como parámetros en los procedimientos almacenados (cuando ejecutar comandos SQL en aplicaciones ASP.NET pasamos objeto DataTable como parámetro para el procedimiento almacenado see here for an example)

El problema es que cuando se ejecute comandos SQL (ejecute el procedimiento almacenado) desde ASP.NET obtenemos un error:

The EXECUTE permission was denied on the object 'ourTableType', database 'ourDatabase', schema 'ourSchema'.

¿Por qué es así? ¿Por qué tenemos que establecer el permiso en los tipos de tabla definidos por el usuario? ¿Por qué no es suficiente tener un permiso establecido solo en el procedimiento almacenado que lo usa? Y si tenemos que establecer que no importa qué, por qué no hay ningún tipo EXECUTE permiso para establecer en la ventana de propiedades en absoluto (sólo puedo ver Control, References, Take Ownership, View Definition)?

Lo que tampoco entiendo es que la fijación de permiso para Control en la ventana de propiedades resuelve el problema y el procedimiento almacenado se ejecuta sin problemas.

+3

posible duplicado de [parámetro Tabla valioso en un procedimiento almacenado obtiene permisos de ejecución de error negado] (http://stackoverflow.com/questions/2244217/table-valued-parameter-in-a-stored-procedure- gets-execute-permissions-denied-erro) –

+0

¡gracias! He buscado, pero claramente no es lo suficientemente bueno:/ – Janez

+0

Intenta poner 'AS dbo' al final. De esta manera: 'GRANT EXEC ON TYPE :: [schema]. [Typename] TO [User] AS dbo'. Trabajó para mi. – Jonathan

Respuesta

132

Realmente espero que haya resuelto esto por ahora, ya que la pregunta es casi 4 meses de edad, pero en caso de que no tienen, esto es lo que creo que es la respuesta.

GRANT EXEC ON TYPE::[schema].[typename] TO [User] 
GO 
+0

Esto funcionó para mí cuando tuve exactamente el mismo problema. – mwgriffith

+3

Has guardado el día. ¡Upvote y Gold Star! – granadaCoder

+5

Mis 2 centavos: Dependiendo de su mecanismo de autenticación de conexión, es posible que deba otorgar exec al grupo Público. Por lo tanto, su concesión se vería así: GRANT EXEC ON TYPE :: [schema]. [Typename] TO [Public] GO – dotnetguy

2

Si su procedimiento almacenado está utilizando sql dinámico, lo que significa que @sql se genera y luego se ejecuta a través de exec @sql, necesitará permiso otorgado en las tablas subyacentes.

One work-around is to modify to stored procedure to run as a different user. Si lo haces funcionar como SELF, se ejecutará debajo del creador del proceso almacenado, que es extremadamente peligroso. Sin embargo, si no tienes otra opción:

CREATE PROCEDURE dbo.usp_Demo 
WITH EXECUTE AS SELF 
+1

Thx para señalar esto. Pero el procedimiento almacenado no tiene ningún sql dinámico en él. Solo declaraciones generales de tabla "INSERT INTO" y "UPDATE" para las cuales este usuario tiene todos los permisos que necesita. Además, este usuario/inicio de sesión está especialmente reservado/creado para que esta aplicación ASP.NET pueda conectarse a esta base de datos y solo ejecutar procedimientos almacenados (no crear etc., el creador siempre es ''sa''). – Janez

Cuestiones relacionadas