FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#21
|
|||
|
|||
Jack
Entiendo tu problema, y no se porque no te funciona, a mi me funciona correctamente. Te paso mi codigo para que lo revises respecto al tuyo. Solo añadir que tambien debes crear un trigger para beforeinsert
|
#22
|
|||
|
|||
Gracias por contestar
Gracias a todos por contestar, ( yo prefiero sin sarcasmos ), pero lo que me explicaís no es lo que pregunto. Ya veo que como Lepe dice el stock se queda a cero, pero antes de la modificación habían 10 unidades old.unidades, luego de la modificación hay 15 new.unidades, de donde sacas que ahora el stock se queda = 0. Digo que habra +10 -15 = -5. Si pongo 10 y quito 10 entonces si estoy igual. No pegunto si la secuencia de sumas y restas esta bien.
Mi pregunta es si el update de la tabla stocks puede fallar al grabar la linea de venta e ir a actualizar el stock en los triggers after insert, before update, after delete de la linea de ventas. Esa es mi pregunta, la secuencia lógica del programa no me falla, lo he probado con muchos casos y calcula bien el stock ( al borrar, al modificar y al añadir lineas nuevas, lo hace bien, suma y resta cuando toca ). El desajuste ocurre cuando hay muchos movimientos o cuando hay varios usuarios trabajando o por algún motivo que yo no logro comprender. Bien es cierto que utilizo un dbgrid, haciendo un commitretaining inmediatamente despues del post. Si esto no funciona que alguien me explique 2 cosas. a: para que esta el dbgrid, b: para que esta el commitretaining. También es cierto que leí hace años en alguna página que se desaconsejaba el uso del commitretaining, aunque como he dicho antes en las pruebas que realicé en mi ordenador parecía que funcionaba bien. Otra cosa a la que no puedo renunciar es a que el stock se actualice siempre a cada linea de venta, no al final de la introducción de cada documento, repito, necesito que sea al insertar una nueva linea o al actualizar una linea ya insertada con anterioridad. Estuve hace tiempo tentado de utilizar un stringgrid para trabajar, pero no lo ví operativo y la estética que le pude dar no fue nada de mi agrado. Despues de todo lo dicho, repito la pregunta. Tengo una tabla linventas LV., dos campos LV.articulo, LV.unidades. Inserto una linea nueva LV.Articulo = 'A1', LV.Unidades = 25. La tabla LinVentas tiene un trigger after insert, donde hago lo siguiente a una tabla Stocks. ( esta asegurado que en esta tabla existe un articulo A1 ) En la tabla stocks queda ST.Articulo = 'A1', ST.TotalUnidades = 25. Utilizo la misma lógica con los trigger after delete, before update, after update de la tabla linventas. Esto se puede hacer o hay algún motivo por el que no se deba hacer este sistema de actualización de stocks. ( Las transaciones de las lineas finalizan con un commitretaining. Podría ser que hubiera una situación de introducciones de lineas de ventas de varios usuarios concurrentes ( +10). Yo solo preguntaba esto, me disculpo si no lo pregunte bien o si dije algo no conveniente al leer vuestras contestaciones. Cuando he preguntado algo siempre me habeís contestado amablemente y yo lo he agradecido siempre. Esto del stock me tiene muy preocupado. Actualmente he reprogramado todo el sistema y ya no lo hago de esta manera, aunque aún lo estoy probando, pero si que utilizo este sistema para otros menesteres. Es por eso que insisto tanto en la pregunta. Gracias de antemano. |
#23
|
||||
|
||||
Cita:
Puede fallar? Si. Pero para eso son las transacciones. Existen diversos niveles de transaccion, con diversas garantias y promesas. Puedes (y deberias) leer los docs al respecto: http://www.firebirdsql.org/manual/is...nsactions.html ------- Un problema con la forma como casi siempre se hace esto es que el proceso es *destructivo*, y una vez completo, es prácticamente imposible reconstruir lo que paso. Sin embargo, existe una forma de diseño que garantiza la reproducibilidad y el rastreo preciso de lo que pasa, y es muy similar a como funciona la contabilidad (Contabilidad bien echa NUNCA hace ediciones o borrados, solo inserta pa' delante): http://www.codeproject.com/Articles/...Event-sourcing En resumen, debes guardar un log de cada pasa que se ejecuta, y hacer un replay para reconstuir el valor actual. Eso es lo que hace una BD con su log de transacciones. En el modelo comun, tienes: UPDATE Producto=1 Cant = 2 WHRE Id=1 Cuando esto termina, no sabes que paso antes. El proceso es *destructivo* En cambio, si lo vuelves un log: Inv ID=1 ADD Producto=1 Cant = 1 Inv ID=1 UPDATE Producto=1 Cant = 2 Inv ID=1 ADD Producto=2 Cant = 3 Inv ID=1 DELETE Como vez, al hacer esto asi, tenes un log inmutable que puedes evaluar y saber exactamente que paso, en que orden, etc. Es la forma segura de darle la maxima integridad y fiabilidad (y tiene otros beneficios, pero dejemoslo asi por ahora). Tambien, considero que es la forma correcta de implementar un inventario. P.D: Para la velocidad de consultas, puedes tener una tabla auxiliar que mantiene el valor actual desde los triggers del log. Es *mas* trabajo, pero es la forma de tener una auditoria perfecta y fiable.
__________________
El malabarista. |
#24
|
||||
|
||||
Cita:
__________________
Felipe Eduardo Ortiz López. Delphi programmers does it recursively... "Un programador, es un creador de universos en donde sólo él es responsable. Universos de complejidad prácticamente ilimitada que se puede crear en forma de programas de ordenador." - Joseph Weizenbaum. Témele a los profetas... y a aquellos que están listos para morir por "la verdad", ya que como regla general hacen morir a muchos otros con ellos, frecuentemente antes que ellos, y a veces en lugar de ellos. — Umberto Eco |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Control Stock Simple | mantraxer21 | Varios | 7 | 21-03-2014 22:20:06 |
Control de Stock y Precios de Ventas | cmm07 | Varios | 6 | 14-01-2012 03:32:29 |
control de stock en delphi | ingmichel | Varios | 5 | 01-08-2007 23:54:40 |
Control de stock por almacenes. | Producto77 | SQL | 29 | 26-02-2007 15:51:30 |
|