SQL - Trigger - Disparador

En ésta ocasión quería comentarles como los Triggers en SQL, resolvieron un problema en un proceso semi automatizado.

Para empezar y para los que no saben, les voy a definir que son los triggers. 

 "objeto que se asocia con tablas y se almacena en la base de datos. Su nombre se deriva por el comportamiento que presentan en su funcionamiento, ya que se ejecutan cuando sucede algún evento sobre las tablas a las que se encuentra asociado. Los eventos que hacen que se ejecute un trigger son las operaciones de inserción (INSERT), borrado (DELETE) o actualización (UPDATE), ya que modifican los datos de una tabla" (wikipedia).

En muchas situaciones son muy útiles... y en éste caso lo digo por experiencia. 

Les planteo la situación y el problema que surgió.

En un sistema que administro hubo un cambio en la legislación que obligaba a tener en cuenta cierta información cuando se realizaba un comprobante, en particular un rango de fecha. 

La recolección y generación de los comprobantes está automatizada:

1. Se genera un comprobante / etiqueta con un código QR, en el cual se codifica toda la información necesaria para a posterior emitir un comprobante. 
2. Se lee la etiqueta con un colector de datos QR, En el se desarrollo una app para que de lecturas consecutivas genere un archivo .txt con todas las lecturas realizadas. 
3. El archivo .txt se carga en un sistema el cual genera un comprobante por cada registro en el sistema ERP
4. El Sistema ERP por último, autoriza los comprobante.

El problema surgió en el paso 4, cuando la autorización del comprobante no se pudo realizar por falta de unos datos. 

Análisis y propuestas de solución

La primera solución pensada fue, listo, no hay problema. El dato lo tengo cuando genero la etiqueta, lo incluyo en el QR para ser utilizado en la generación del comprobante en el sistema ERP y la autorización se realice sin problemas. Muy linda y simple..... pero. El sistema que genera el comprobante en el ERP, utiliza una apertura la cual no tiene en cuenta los nuevos parámetros.

La segunda opción, y la menos deseada, modificar cada uno de los comprobantes manualmente por un operador, para poder autorizar los comprobantes. Pero esa "solución" implica un retroceso en el proceso (se pasa a realizar una tarea manual), con el agravantes de los posibles errores de tipeo. Cuando se dimensionó la situación, se observa que la cantidad diaria en promedio de comprobantes es de 100, por lo que tampoco era viable. 

Finalmente, y como pueden sospechar por el titulo del blog, se pensó en una solución utilizando los Triggers del SQL, en este caso SQL Server. Primero mediante la herramienta Profiler, se depuró las acciones que hace el ERP y donde se guarda la información del período en la generación del comprobante. Una vez identificada la tabla, se programó un trigger que se ejecute cuando se inserta una fila en dicha tabla, modificando los dos parámetros del período, teniendo en cuenta que si ya tiene dato, no se haga el cambio. De esta manera, se encontró una solución intermedia, permitiendo y dejando todo el proceso intacto y transparente para el usuario.