Aprendiendo SQL Server

El portal xkcd publica esta viñeta sobre inyección de código en SQL Server : Los peligros de llamar a tu hijo DROP TABLE Tratado con gran sentido del humor , esta cómica situación nos pone en alerta frente a la inyección de código SQL Server , que puede suponer una vulnerabilidad seria para nuestras bases de datos. Una aplicación que no compruebe los datos que en ella se introducen a través de aplicaciones externas está expuesta al desastre . En el cómic se introduce una instrucción DROP TABLE en medio del supuesto nombre de un niño inscrito en un colegio. Al introducir el falso nombre en el sistema informático del centro, el resultado es catastrófico: la tabla de estudiantes es eliminada por completo . La Wikipedia presenta un ejemplo similar para demostrar en qué consiste la inyección SQL Server, así como diversas soluciones a adoptar, dependiendo del lenguaje de programación de la aplicación: "Por ejemplo, asumiendo que el siguiente código reside en una  aplicac...

En ocasiones necesitamos que nuestras consultas devuelvan valores constantes. Por ejemplo, de manera muy sencilla, podemos tener una consulta como la siguiente: Si necesitamos recuperar los valores devueltos por la consulta en un recordset de ADO.NET, por ejemplo, ¿qué tipo de datos debemos esperar de columnas de este tipo? La respuesta: depende. Depende del tipo de constante que hayamos introducido. Si se trata de un número que no desborde los 4 bytes de capacidad de un entero ( int ), como en el caso del 1 de nuestra consulta anterior, éste será el tipo de datos de dicha constante. Si escribimos la constante entre comillas simples, SQL lo tratará como un varchar del tamaño del literal que hayamos escrito. Por ejemplo: Creará un campo varchar(1). Éste sería nvarchar(2) si hubiésemos escrito lo siguiente, indicando un literal Unicode mediante la N delante del literal: Para un número con parte decimal, el tipo de datos será numeric ; lo mismo que para un número de tam...

Resumen: En cada país, en cada idioma, en cada región... usamos un formato diferente para representar las fechas. SQL Server permite comparar columnas que almacenan fechas contra cadenas de textos que convierte internamente al tipo de datos necesario. Sin embargo, según la configuración regional del servidor, la misma cadena puede ser interpretada de diferentes formas, generando errores que incluso pueden pasar inadvertidos. Para solucionarlo existe un formato de fecha estándar e independiente de cualquier configuración que hay que usar siempre: 'yyyymmdd'.

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.

Microsoft publica en la MSDN la " Lista de características desusadas del motor de base de datos de SQL Server 2012 " o, lo que es lo mismo, las deprecated features . Esta lista es útil para mantener nuestra aplicación actualizada , de tal forma que podamos seguir usando las nuevas funcionalidades de las sucesivas versiones SQL Server. Mantener en nuestro código alguna característica marcada como obsoleta o en desuso implicaría que no podríamos ejecutarlo en la versión de SQL que ya no la soportase. Pues bien, en dicha lista aparecen tanto las características que no serán soportadas en la próxima versión de SQL Server como las que estarán en desuso en futuras versiones. Esta segunda lista es muy amplia, pero si leemos detenidamente en ella nos encontraremos con, al menos, una característica que nos llamará la atención : "Not ending Transact-SQL statements with a semicolon." Es decir, Microsoft pretende que deje de ser opcional -como lo es hasta ahora- finaliz...

¿Alguna vez has necesitado obtener una muestra de datos totalmente aleatoria de tu base de datos? En SQL Server es posible hacerlo, mediante la cláusula TABLESAMPLE , que se aplica a la definición del origen de datos que vamos a recuperar con la cláusula FROM . TABLESAMPLE nos permite indicar un número de filas o un porcentaje de filas a devolver , de la siguiente manera: --devuelve el 10% de las filas totales --(dependiendo del tamaño de los registros en la base de datos, no del número de filas). SELECT * FROM YourTable TABLESAMPLE (10 PERCENT)  --devuelve una muestra de 15 filas del conjunto de resultados SELECT * FROM YourTable TABLESAMPLE (15 ROWS)  Algunas consideraciones a la hora de usar TABLESAMPLE incluyen: No se puede usar en la definición de vistas No se puede usar en la definición de funciones de tabla inline No se puede aplicar a tablas devueltas por funciones tipo tabla

Pinal Dave ha anunciado a través de twitter el ganador del premio por resolver los dos puzzles SQL que planteaba ahora hace unos días, y de los que nos hicimos eco en este mismo blog . Pues bien, parece que nuestras respuestas eran correctas :) The winner of 2 T-SQL Puzzles and Win USD 50 worth Amazon Gift Card bit.ly/Odx9Wy is @ jaimeml - Congratulations! — Pinal Dave (@pinaldave) octubre 3, 2012 Great! :) RT @ pinaldave : winner of 2 T-SQL Puzzles and Win USD 50 worth Amazon Card bit.ly/Odx9Wy is @ jaimeml - Congratulations! — Jaime Mtnz Lafargue (@jaimeml) octubre 3, 2012

Recientemente, Pinal Dave publicó en su blog SQL Authority un post con dos puzzles para Transact SQL. La curiosidad nos hizo intentar averiguar las respuestas, y aquí va lo que descubrimos (podéis intentar adivinarlas antes de leer la solución):

SQL Server 2012 lleva tan solo unas semanas entre nosotros y, como ocurre con cada nueva versión de un producto, lo primero en lo que nos hemos fijado es en sus novedades . En lo que se refiere a su lenguaje de programación, el Transact SQL, la que más nos llama la atención es la introducción de las Secuencias, o SEQUENCE .

En ocasiones podemos querer obtener un resultado que sea un subconjunto de otro resultado, ordenado de una forma concreta. Además de la cláusula TOP (que nos permite obtener un número o porcentaje concreto de filas sobre el total), SQL Server vio como se le añadían las funciones de ranking a partir de su versión de 2005. Una posible aplicación de ellas serviría para resolver la siguiente cuestión: ¿Cómo devolver la enésima fila de un conjunto de resultados?

Imaginemos que queremos obtener el valor máximo de una columna de una tabla que puede contener valores nulos y que, en caso de no existir ningún valor en ella o ser todos los existentes nulos, deseamos obtener un cero.

En esta entrada pretendemos explicar los diferentes resultados obtenidos por distintas construcciones de consultas que, aparentemente, deberían producir el mismo conjunto de resultados. Así, veremos las diferencias entre filtrar los resultados de una query en la unión (Join) mediante condiciones ON y mediante cláusulas WHERE.

Seguramente, muchos de vosotros habréis usado en innumerables ocasiones la función de T-SQL COUNT , que no hace sino devolver un número de registros: de una tabla, de un conjunto de resultados, etc... En una de sus aplicaciones, combinado con el DISTINCT -uno de los dos argumentos que admite- COUNT nos devuelve el número de valores únicos no nulos de la tabla o conjunto de resultados que estemos consultando. Pero ¡ojo! Cuidado con la sintaxis , o podemos obtener el valor equivocado sin darnos cuenta. No es lo mismo: SELECT COUNT (DISTINCT NombreCampo) FROM NombreTabla que: SELECT COUNT(*), DISTINCT NombreCampo FROM NombreTabla

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