¿Ejecuta una aplicación de consola desde SQL Server después de que la actualización de la tabla se active de forma asincrónica?

Tengo problemas para encontrar la mejor manera de resolver mi problema, tenga en cuenta que estoy abierto a mejores formas de llevar a cabo esta tarea.¿Ejecuta una aplicación de consola desde SQL Server después de que la actualización de la tabla se active de forma asincrónica?

Lo que tengo que hacer es, después de valor de una fila en mi tabla se actualiza, necesito usar 2 campos de esa tabla como parámetros para una aplicación de consola. Ahora mismo puedo lograr esto estableciendo un disparador en la tabla y luego usando xp_cmdshell para ejecutar la aplicación con los parámetros. Sin embargo, necesito hacer esto de forma asíncrona para que mi procedimiento almacenado no se cuelgue mientras espera a que finalice la aplicación de la consola.

Tal vez estoy haciendo esto de la manera incorrecta.

estoy usando SQL Server 2008

EDITAR - La respuesta de Andriy M parece ser el mejor momento, pero como se ha dicho en los comentarios que necesito una manera de hacer que esto suceda "instantánea". ¿Es posible llamar a un trabajo desde un SP o un Trigger? o tal vez otra forma de lograr un resultado similar?

gracias por la ayuda de todos.

EDITAR - Elegí la respuesta a continuación porque me ayudó a llegar a una solución mejor. Lo que terminé haciendo fue crear un trabajo que solo consulta mi tabla con otra que realiza un seguimiento de las filas actualizadas. luego cuando tengo las filas necesito actualizar uso xp_cmdshell para ejecutar mi aplicación con los parámetros especificados. esta solución parece estar funcionando sin problemas hasta el momento.

Fuente

2011-12-27 kds6253

¿Qué hace su aplicación? – UnhandledExcepSean

realiza alguna operación por lotes basada en los valores actualizados en mi tabla, no puedo entrar en detalles mucho más que eso. – kds6253

¿Necesita hacer algo fuera de la base de datos? – UnhandledExcepSean

Existe otra desventaja al ejecutar su aplicación directamente desde el desencadenador. Tiene que ver con el hecho de que generalmente puede haber más de una fila actualizada. Para contabilizar eso en su desencadenante, probablemente tenga que organizar un ciclo sobre las filas actualizadas y ejecutar la aplicación para cada una individualmente. Los cursores se suelen considerar como un último recurso, y aquellos en un desencadenante lo son aún más.

En una situación como esta que lo más probable es considerar la creación de un trabajo del Agente SQL que lee los valores actualizados de una tabla dedicada poblado por un disparador. El trabajo todavía tendría que usar un cursor, creo, pero su desencadenador no lo haría, y el punto principal es que ejecutar la aplicación desde el trabajo no detendría su proceso de trabajo principal.

Fuente

2011-12-27 19:31:37

Esta parece ser la mejor solución. El desencadenador llama al trabajo que debe consultar la tabla y obtener la información para los parámetros y luego ejecutar mi app.exe desde xp_cmdshell dentro del trabajo. – kds6253

¿Alguien ve algún problema con esta lógica o posibles mejoras? – kds6253

@ kds6253: No soy muy hábil en el manejo de trabajos SQL, en particular, nunca escuché acerca de invocar trabajos desde desencadenadores. Solo estaba pensando en un disparador que simplemente poblaría una determinada mesa, nada más. El trabajo que mencioné se ejecutaría según un cronograma y sondearía la mesa. Después de encontrar nuevas filas, comenzaría a invocar la aplicación para cada fila, una tras otra. Si un disparador puede * directamente * comenzar el trabajo, lo vería como una buena bonificación. –

Creo que debería desarrollar un procedimiento almacenado extendido (DLL) en lugar de llamar a una aplicación de consola utilizando xp_cmd_shell.

Fuente

2011-12-27 18:50:31 Baatar

¿Existe alguna alternativa a los procedimientos almacenados extendidos? – kds6253

[La programación del procedimiento almacenado extendido está en desuso] (http://msdn.microsoft.com/en-us/library/ms143729.aspx) –

No lo sabía. Gracias. – Baatar

Sugeriría usar un procedimiento CLR, ya que le da mucho más control sobre el proceso. Pero usted puede hacer esto con xp_cmdshell.

Para hacer esto se puede escribir un archivo por lotes que se le invoque con xp_cmdshell. Dentro del archivo por lotes, inicie la aplicación de la consola con los parámetros adecuados utilizando el comando START. Esto disparará su proceso de forma asincrónica. El archivo de proceso por lotes y la invocación xp_cmdshell volverán inmediatamente.

Fuente

2011-12-27 19:18:13 mwigdahl

Un ejemplo completo de escribir y registrar un procedimiento de CLR es más de lo que puedo hacer aquí. Hay excelentes ejemplos en línea. Si el truco 'START 'no funciona, también puedes probar el programa' AT'. Esto se puede usar para programar un trabajo para ejecutar en el futuro. Si lo configura para, digamos, uno o dos segundos en el futuro, debería funcionar. Insisto, sin embargo, que cualquiera de estos enfoques 'xp_cmdshell' sería un truco. Realmente deberías mirar el diseño fundamental del problema si puedes. – mwigdahl

En su activador, coloque un mensaje en una cola de Service Broker para cada fila que se actualizó. Escriba un procedimiento almacenado que procese los mensajes fuera de la cola. Establezca el procedimiento almacenado como el procedimiento almacenado de activación para la cola.

Fuente

2011-12-27 23:39:54

¿Ejecuta una aplicación de consola desde SQL Server después de que la actualización de la tabla se active de forma asincrónica?

Respuesta

Cuestiones relacionadas