Aprendiendo SQL Server

En algunas ocasiones, buscando problemas de rendimiento en bases de datos, nos enfrentamos a una lista de consultas que son las causantes de dichos problemas. Una vez obtenida esa lista de consultas, el problema a resolver es: ¿ Dónde están codificadas esas consultas ? ¿Forman parte del código de nuestra aplicación o, por el contrario, su código T-SQL está en alguno de nuestros objetos de la base de datos; véase un trigger, un procedimiento almacenado, una función o una vista? Si se da el segundo caso, y no somos capaces de reconocer el objeto que está ejecutando la consulta que buscamos, disponemos de una vista de sistema (entre las vistas de objetos del catálogo) que nos ayudará a encontrar dónde se esconde: sys.sql_modules . Así, una consulta como la siguiente es la que necesitamos para encontrar el código: * Si tu versión de SQL Server es anterior a SQL Server 2005, hay que usar la tabla de sistema sys.syscomments .

Los procedimientos almacenados de SQL Server pueden devolver valores bien sea a través de su valor de retorno, bien sea mediante los denominados parámetros OUTPUT . Ahora bien, para que un procedimiento almacenado nos devuelva el valor de un parámetro OUPUT deberemos tener en cuenta dos cosas : que sea declarado como OUTPUT en el propio procedimiento y que en la ejecución del mismo se especifique la palabra clave OUPUT junto al parámetro en el que queremos que se nos devuelva el valor.

Ejecutando un procedimiento almacenado que, a su vez llamaba a un método en un assembly instalado en el CLR de SQL Server, obtenía un error inesperado. El error me decía que una de las instrucciones SQL ejecutadas dentro del assembly estaba fallando. Sin embargo, si omitía el procesamiento del error, me daba cuenta de que la sentencia se había ejecutado correctamente.

Antes que nada, permitidme presentar este nuevo blog en el que un programador cualquiera, de una empresa cualquiera, tratará de contaros el día a día de sus peripecias con Microsoft SQL Server . Como dicen que la experiencia es un grado y que de los errores se aprende, intentaré desde estas líneas que l@s mí@s puedan serviros cuando os veáis en las mismas diatribas que me han llevado a escribir estas líneas. Sin más, allá vamos. Entre las muchas instrucciones de configuración que nos ofrece Microsoft SQL Server, hay una cuyo uso no parece aportar demasiado, pero que es vital si no queréis enfrentaros a "fenómenos paranormales" en algunas de vuestras queries. Se trata de SET NOCOUNT ON