Cómo suprimir errores en proyectos de DB

Últimamente estoy teniendo que pelearme mucho con proyectos de bases de datos de Visual Studio y no puedo decir que lo esté disfrutando.

Sin embargo he de reconocer que una de las cosas más interesantes que tienen es la posibilidad de compilar y analizar estáticamente el código TSQL de estos proyectos, como si se trata de código C# o VB.NET.

Siendo como es una ventaja para escribir código primero correcto y, posteriormente, más óptimo y, en general, de mejor calidad, en ocasiones cabe la posibilidad de que queramos hacer caso omiso a los warnings y errores que nos lanza.

A diferencia de sus equivalentes en código procedural, con los proyectos de base de datos no tenemos ni directivas pragma ni atributos SuppressMessage que nos permitan ignorar estas advertencias. Sin embargo no estamos perdidos del todo, tenemos dos posibles estrategias a seguir:

Fuerza bruta

Si eres de los que no le importa usar la fuerza bruta para resolver sus problemas lo más rápido posible, ésta es tu opción: simplemente eliminar todos los errores del tipo para todo el proyecto.

En la siguiente imagen se pueden ver las propiedades del proyecto de base de datos, en concreto la pestaña de Build. En ella podemos introducir los números correspondiente a las reglas que queremos ignorar para el proyecto completo.

image

El modo preciso

La desventaja clara de la opción anterior es que perderemos ese tipo de avisos para posteriores errores que pudiéramos introducir en el proyecto. Sería mucho más práctico si pudiéramos reducir el alcance de la supresión a, por ejemplo, un único fichero, sabiendo que en los proyectos de bases de datos cada fichero contiene un único objeto de la base de datos.

Pues bien, por suerte es posible y además es muy sencillo. Basta con pinchar en el fichero deseado y mostrar las propiedades del mismo. Veremos una caja de texto denominada “Suppress Warnings” en la que podremos introducir el código que representa la regla a suprimir. En la siguiente figura se puede ver.

image

Gracias a esta opción podremos seguir recibiendo los avisos de este error en otros ficheros en los que nos equivoquemos.

Usuarios, permisos y SQL Server

Recientemente me encontré ante la situación de tener que configurar, en un proyecto de Database de Visual Studio 2008, una serie de usuarios, permisos y roles.

En concreto, necesitaba crear un rol que pudiera ejecutar procedimientos almacenados y hacer SELECTs sobre un determinado esquema. A este rol, a su vez, pertenecería un usuario que también debía crearse dinámicamente en el script. Tras una mañana de investigación, estas son mis conclusiones.

Logins y Users

En SQL Server hay que distinguir entre Logins y Users. Los Logins se crean a nivel de servidor de base de datos. Pueden crearse como Logins de SQL Server, o pueden crearse a partir de una cuenta Windows, lo que en general es más seguro por utilizarse la autenticación integrada. En mi caso era precisamente eso lo que pretendía hacer, crearlos a partir de una determinada cuenta Windows. Esto es muy sencillo de hacer, basta un comando como el que se puede ver a continuación:

USE [yourdb]
GO
CREATE LOGIN [YourDomainYourUser] FROM WINDOWS
GO

Sin embargo, esto tiene una pega: no se puede hacer en los proyectos de base de datos de Visual Studio 2008, o al menos yo no he encontrado el modo. Tiene su sentido, de todas formas, puesto que estos proyectos no dejan de ser la creación de una base de datos concreta, y no debería afectar a la configuración del servidor en sí.

Una vez creado el Login, ya podemos crear un usuario y asociarlo a él. Esta parte sí se puede añadir al proyecto de BD de VS2008, en concreto en la carpeta Users dentro de Security. El TSQL necesario sería algo así:

CREATE USER [YourDomainYourDbUser] FROM LOGIN [YourDomainYourUser]
GO

Bien, con esto ya tendríamos nuestro usuario concreto de la base de datos creado, asociado a un Login a nivel del servidor.

Roles y permisos

El siguiente paso es crear el rol al que vamos a asociar el usuario que recién hemos creado. Este rol va a pertenecerle a dbo. No podemos darle sus permisos directamente en el script que se crea en la carpeta Database Roles de Security, esa parte tendremos que añadirla en un script de Post-deployment. Así que en el script de creación del rol simplemente tendríamos la siguiente sentencia TSQL:

CREATE ROLE [YourNewRole] AUTHORIZATION [dbo]
GO

Quedarían dos pasos por ejecutar: darle los permisos al rol que necesite y asociarle el usuario que creamos al principio.

La primera parte se completa con una sentencia parecida a ésta. Sería necesario indicar qué esquema de los existentes en la base de datos, va a poder el rol ejecutar sus SPs.

GRANT EXECUTE ON SCHEMA ::[YourSchema] TO [YourNewRole]
GO

En cuanto a la segunda, bastaría algo como lo que sigue, apoyándonos en uno de los procedimientos almacenados del sistema:

EXEC sp_addrolemember N'YourNewRole', N'YourDomainYourUser'
GO

Bibliografía: