Por ejemplo, supongamos que deseamos que por cada cambio en una tabla se haga un registro en otra, guardando la clave del usuario que hizo la modificación. Hablamos de usuarios de aplicación, no de la cuenta de SQL Server asociada a la conexión.
También es posible que queramos medir el tiempo que tarda un lote de sentencias en ejecutarse. El problema es que después de cada instrucción GO, o después de una transacción fallida, todas las variables que hayamos declarado desaparecen.
Ya que en SQL Server no existen las variables de sesión, tenemos que encontrar un mecanismo donde podamos almacenar este tipo de información contextual.
Afortunadamente, a partir de SQL Server 2005 existe algo que nos puede ayudar. Se llama CONTEXT_INFO, y es un espacio de almacenamiento asociado a la conexión actual. La información que almacenemos aquí permanece durante toda la conexión.
Tampoco es mucho lo que podemos guardar en CONTEXT_INFO: apenas 128 bytes. Más que suficiente para almacenar un número, como la clave del usuario de aplicación o el tiempo de ejecución de los que hablábamos más arriba.
¿Cómo se usa?
Crearemos un procedimiento almacenado para establecer el CONTEXT_INFO y una función con la que podremos recuperarlo, incluso desde un disparador:
Como podemos observar, hay que lidiar con la conversión a binario, incluyendo la longitud de la cadena (¿recuerdan los indicadores de longitud de cadena de C++ y Pascal?)
Con estos objetos creados podemos invocar al procedimiento almacenado desde alguna rutina de la aplicación cliente para establecer la clave del usuario, y llamar a la función para recuperarla desde nuestros disparadores.
CONTEXT_INFO no puede establecerse en NULL. Si queremos de algún modo "restablecerlo" podemos usar la siguiente sentencia: SET CONTEXT_INFO 0x. Con ella, la función que creamos devuelve NULL.
Comentarios
Publicar un comentario