FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#10
|
|||
|
|||
Gracias a todos. La idea de Neftali me pareció buena, aunque no he encontrado la manera de que el Firebird ejecute una tarea programada. Os comento cómo ha quedado, por si en posteriores búsquedas alguien lo necesita.
Idea base: Mantener disponibilidad y estadística de un artículo por cada delegación sin saturar el servidor: Primero, crear una tabla con los artículos que se han vendido, pedido, comprado, traspasado, presupuestado, ajustado:
Segundo, meto en todos los triggers de las tablas que provoquen movimiento del artículo (preventas, pedidos, presupuestos, traspasos, compras, ventas...) indicado que ese artículo debe recalcularse sus parámetros de disponibilidad, pongo ejemplo de uno de estos triggers:
El autonomous transaction es porque he tenido frecuentes deadlocks (mucha intensidad de entrada de datos). Sólo se inserta una única vez cada artículo. Si se ha movido 300 veces el artículo, no tengo que calcular 300 veces su disponibilidad, sólo una única vez cuando termine de moverlo 300 veces. El siguiente paso ha sido crear el STORE PROCEDURE que se dedica a actualizar la disponibilidad por delegaciones de los artículos que estén contenidos en esta tabla. El bucle se detendrá cuando se hayan actualizado todos los artículos o se detecte que empiezan a entrar nuevos artículos en la tabla.
Este proceso debe estar especialmente protegido, ya que se ha de ejecutar en modo desatendido, y si da un problema, no debe bloquearse el proceso, de ahí el autonomous transaction (por si el proceso se lanzara por error varias veces) y el When Any, para que registrar las incidencias. Por último, he creado otro Store Procedure que ponga en marcha el bucle si hace más de 30 segundos que no se actualiza la tabla de articulos a procesar:
Tengo un programa en delphi funcionando sólo en el servidor dedicado ha lanzar sincronizadores, actualizadores, chequeadores... y he metido un timer para que cada 60 segundos se lance el TIMER_EXECUTE. En hora punta (08:00-09:00) se han producido 7345 líneas de venta, en los que se ha vendido 720 productos diferentes, mientras se está generando líneas de venta el proceso de actualización de disponibilidad (stock, pedidos, fechas prevista de entrega, activación de punto de pedido, descuento de depositos...) no se ejecuta... cuando lleva 30 segundos sin que se muevan productos, se procesa los archivos de disponibilidad para esos 720 productos, y no se pasa el proceso 7345 veces, como ocurría antes. Lleva un par de días en funcionamiento y por ahora bien, me ha dado un sólo DeadLock porque creo que tres procesos han ido a actualizar el mismo artículo en el mismo milisegundo... y a petado el AIUD_EXTRACTO (no entiendo porqué, ya que está en una transacción autónoma y no debería estar bloqueado el update en ninguna trasacción). Lo único que me preocupa es que el ejecutable que lo lanza, a veces se cae... falla algún proceso, se reinicia el servidor, alguien lo para para mantemiento, pierde la conexión con alguna bases de datos...
__________________
Amar al mundo apasionadamente. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Store Procedure | shoulder | SQL | 5 | 06-06-2019 17:18:51 |
Store procedure | sancarlos | MySQL | 3 | 30-01-2008 19:51:49 |
Store Procedure | sépoco | MS SQL Server | 5 | 10-01-2008 16:11:54 |
Store procedure php | jorgito | MySQL | 1 | 06-06-2006 08:55:12 |
store procedure | ronimaxh | Firebird e Interbase | 2 | 24-06-2003 20:20:22 |
|