El Bruno

Buenas,

desde hace unos días sigo con cautela un blog donde un compañero ha descubierto algunas de las capacidades extendidas que posee Microsoft SQL Server 2005. Como muchos saben SQL Server posee una serie de stored procedures extendidos que brindan unas funcionalidades muy interesantes, pero que en muy pocos casos he encontrado la necesidad de utilizar (en realidad creo que nunca)

Por mencionar algunos podría hablar de xp_fileexist, para verificar si existe un archivo; o xp_regread para leer una entrada del registro de windows; o inclusive xp_terminate_process para destruir un proceso a partir de su ID (que peligro !!!). Sin embargo el más peligroso de todos a mi humilde entender es xp_cmdshell. Como la realidad siempre supera a la ficción, simplemente me remitiré a una pequeña experiencia para ilustrar este caso.

Hace unos años, cuando trabajaba con el amigo Iteya y mis semanas se repartían entre Córdoba y Buenos Aires; me llamaron de un proyecto para revisar un problema que tenían con COM+, algunas transacciones y SQL Server. En este tipo de escenarios y cuando de acceso a datos y transacciones hablamos, yo soy bastante práctico; mis premisas son la siguientes:

• La base de datos solo debe realizar acciones de INSERT, UPDATE, DELETE o SELECT
• Se debe acceder a la base de datos utilizando Procedimientos Almacenados
• Los procedimientos almacenados no deben tener lógica dentro de los mismos (ni siquiera un IF)
• La gestión de las transacciones es responsabilidad de a lógica de negocios ... aunque bueno este es un tema aparte :D

Volviendo a esos días, la frase con la que me recibieron fue: "existen casos donde se lanza un proceso de actualización de datos dentro de una transacción, pero si algo falla, el Rollback no elimina los datos". Frente a este escenario, me puse a revisar un poco la configuración del sistema, un poco el código de las clases de negocio y todo parecía estar en orden, sin embargo dentro de un procedimiento almacenado encontré la siguiente línea:

set @command = 'c:\Procesador.exe' + @CommandID
exec master..xp_cmdshell @command

Desde mi más profunda ignorancia pregunté que era "Procesador.exe"; y me encontre con una aplicacion desarrollada en FOX que recibía un parámetro y realizaba algunas acciones de acuerdo al mismo y de la que se esperaba que "mágicamente" utilizase el contexto transaccional en el que se estaba ejecutando la lógica de negocios. Obviamente si en algun momento la transaccion "se cortaba" los datos que había procesado la aplicación de FOX quedaban en ese estado, pero esto era un misterio para el equipo de desarrollo.

Por suerte en las oficinas de informática de las grandes empresas, usualmente no se encuentran motosierras ni sables láser colgados en las paredes, porque creo que después de ver este escenario, mi primer instinto hubiese sido tomar un sable láser y comenzar con la colección de mancos. Pero opté por un pequeño gráfico y de un par de horas explicando como funciona COM+, que son los contextos transaccionales, etc.; y además les dejé las siguientes preguntas para una autoevaluación para los procedimientos que comienzan con xp_ ...

• Si necesito leer el registro de Windows desde mi servidor de base de datos, ¿estoy seguro que no necesito comenzar a separar en un par de layers para asegurar el aislamiento de las capas de mi app?
• ¿Cuál es la razon aparente para verificar si existe un archivo desde el servidor de DB?
• etc.

y como una buena práctica para evitar problemas a futuro, recomiendo realizar un search por "xp_" en un database script para verificar si no estamos tentando al destino.

Saludos @ VS2008 Download home

El Bruno