FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Hola Casimiro. Como decía, se generan muchos documentos, más de 600, en los que se venden los mismos 200 artículos docenas de veces... Una vez que almacén ha sacado la mercancía y se ha cargado para reparto con el chequeo correspondiente de que no falta nada ni sobra nada, se pasa de pedido a albaranes y facturas los 600 documentos para 20 rutas de reparto, desde tres equipos a la vez, imprimiendo y separando documentos en impresoras diferentes para cada ruta. Mi intención es que se generen e impriman los documentos sin recalcular stock ni estadísticas... y a determinadas horas o cuando no haya carga de trabajo, que el servidor haga ese proceso. No quiero que el stock esté mal durante demasiado tiempo, pero es que cuando en los mismos 20 minutos TODOS se ponen a generar documento se ralentiza demasiado por culpa de estar calculando el stock una y otra vez para los mismos artículos. Mejor esperar a que terminen de generarse todos los documentos y que se lance automáticamente... pero todo desde el servidor, porque los puestos no saben cuando terminan los demás.
Otra cosa... ¿¿¿Un store procedure que contenga esta línea carga de trabajo o memoria el servidor??? (a ver qué opináis): WHILE (CURRENT_TIMESTAMP < roxima_ejecucion) DO SUSPEND;
__________________
Amar al mundo apasionadamente. |
#2
|
||||
|
||||
Veamos, el stock es básicamente descontar una cantidad de un campo, algo que lo hace automáticamente un trigger. Algo debe no estar haciéndose bien si dices que se ralentiza el sistema.
En cuanto al bucle que indicas tendrás que probarlo, pero así a simple vista no tiene buena pinta , quiero decir que lo veo innecesario. Yo comprobaría qué es lo que realmente es lento en el sistema para solucionarlo. Porque si estamos hablando de unos cientos de artículos y una decena de puestos de trabajo... eso es una carga inapreciable para una base de datos como firebird o similar. |
#3
|
|||
|
|||
El bucle WHILE DO SUSPEND; no funciona... ya hice las pruebas. Gracias por tu interés Casimiro. Te pediría que obviaras la necesidad que tengo de calcular o no el stock en el trigger. No sólo calcular el stock... es algo complejo y la ejecución del trigger hace que la documentación tarde 80 minutos más de lo que sería realmente necesario, después de estar haciendo pruebas durante varios días en servidores paralelos, de 100 minutos a sólo 20 minutos si desactivo los triggers de mi fichero de Movimientos.
Eso significa que los repartidores tienen que esperar una hora y media entre que le entregan la carga y la entrega de la documentación. En media hora cargan la mercancía en el camión, sería genial entregarles los albaranes y facturas antes de que terminen de cargar y no tengan que estar una hora más esperando. Son muchas horas, 20 repartidores en cada una de las 40 delegaciones que tenemos en España. Mi solicitud al grupo es: ¿Alguien sabe cómo crear una tarea programada en Firebird que se ejecute cada x minutos? (dentro del propio servicio de FB, no mediante un batch o un ejecutable externo)
__________________
Amar al mundo apasionadamente. |
#4
|
||||
|
||||
No he visto en profundidad las especificaciones de las últimas versiones, pero no creo.
|
|
|
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 |
|