FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Alucino.
Que nadie comprenda lo que digo me hace alucinar, vuelvo a explicar que el usuario de mi programa ( no yo sino el usuario que quede bien claro ), graba una linea de venta de 10 lapices, despues una vez ha grabado la linea y descontado el stock de la ficha de lapices, rectifica la linea porque en realidad tenia que haber grabado 20 libretas( vuelvo a decir que el usuario se ha equivocado él y no yo ).
Si esta situación vuestros clientes no la tienen los mios si, y mi deber es que se puedan gestionar estos cambios en la base de datos con lo que nadie de vosotros tiene el derecho de opinar si mi pregunta es buena o mala, tan solo se pide que el que no la comprenda o no la sepa pues que no la conteste, decirme 'que le pregunte a mi abuela no se que', o que 'creía que lo había visto todo' esta totalmente fuera de lugar y es de muy mala educación ya que mi abuela esta ya fallecida. Creía que esta página era para ayudarnos entre gente que trabaja con firebird, y que sufrimos lo indecible por intentar hacer bien las cosas pero veo que no. No sé exactamente desde que año estoy suscrito a esta página, son muchos años y muchos años también trabajando con firebird, nunca jamás se me habría ocurrido contestar a nadie de la manera que aquí se me ha contestado. Una buena noticia para todos estos que me lo han hecho, esta sera la última vez que entre en esta página, jamás volveré a pisar los pies por aqui. Es triste encontrase con gente así por la vida, aunque tengo claro que siempre que tenga que medirme con gente de este tipo, yo estaré infinitamente por encima de ellos, por respeto a los demas y por educación. |
#2
|
||||
|
||||
Hay que ser más humilde, no pasa nada por reconocer que te has equivocado, todos lo hacemos y ninguno nacemos enseñados, se aprende de los errores.
En tu explicación del problema está claro, y así se te ha informado (con bromas sarcásticas, cierto) de que el planteamiento que haces es incorrecto. ¿Y te enfadas porque te han dicho que está equivocado el planteamiento que haces?, yo me alegraría que me dijeran que está mal y así poder solucionarlo. PD. En relación a tu otro mensaje de baja, basta con que no nos visites más. Suerte. |
#3
|
||||
|
||||
Jack... lo siento por como te has tomado todo...
El problema que tienes es de concepto, es muy fácil de solucionar y no tiene nada que ver con Firebird, me explico: Tu haces la interfaz con un ClientDataset, un StringGrid, pero no uses un DBGrid. Dejas que el usuario haga todos los cambios que desee, pero tu transacción solo empieza cuando el usuario le da al botón "Aceptar". Mientras tanto el usuario puede modificar su línea, sus cantidades, todo lo que quiera, eso lo "hace en memoria", no pasa por la Base de datos. Una vez que él lo tiene claro y pulsa "Aceptar", es en realidad cuando empieza la transacción se suma ó se resta y se acabó. Tu error que no terminas de comprender es que el trigger beforepost y afterpost se ejecutan siempre que guardes en la tabla. Ejemplo: "quiero vender 20 lápices" con tus triggers haces lo siguiente: - Empieza la modificación, usuario vende 20 lapices y pulsa botón aceptar: - trigger before post: stock.ventastotales = coalesce(ventastotales,0) - 20 - trigger after post: stock.ventastotales = coalesce(ventastotales,0) + 20 - Se hace el Post y después CommitRetainig. Todo queda grabado. ¿cuanto lápices te quedan en stock.ventastotales? Lo mismo que tenías antes de empezar. Eso es lo que todos te han dicho ya. Me da la impresión que usas un DBGrid y cuando alguien graba una línea del grid haces el post y el commitRetainining, por eso te falla la lógica del negocio. Todo eso que el usuario "se equivoca"... esos errores que comete el usuario los hace "en memoria", en un stringGrid, sin pasar por la Base de datos!!!, o al menos así debe ser!!! ¿lo entiendes ahora? Si el usuario se ha equivocado y ha pulsado el botón Aceptar. Lo que debe hacerse es un apunte rectificativo (no tiene nada que ver contigo ni con programación). Es él, el que debe añadir otro apunte a la tabla stock con concepto "anulación/rectificación en el apunte con ID=33" y en cantidad pone "-20" (si vendió 20 unidades, en este apunte pone que ha vendido "-20" y rectifica los totales de stock). Queda grabado en el sistema que él se equivocó y después lo corrigió. Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. Última edición por Lepe fecha: 31-01-2016 a las 15:13:44. |
#4
|
||||
|
||||
Aunque tomaste una accion drastica, no debería sorprenderte que no te comprendan, y a la vez, que el programa no funcione. Ambos problemas son el mismo problema..
Definir el problema es como tener el 90% de la solución. Entender el problema es la puerta segura y facil al éxito. Por ejemplo, de acuerdo al zen de python: Cita:
Una razon? Porque si las especificaciones fuera realmente correctas y completas, no solo no tendrían ambigüedades sino que serian la explicación exacta y detallada del programa. Un programa entonces, seria la explicación (en términos del lenguaje) concreta de la especificacion. ---- En pocas palabras: Cuanto tienes las preguntas claras, y son claras PRECISAMENTE PORQUE CUALQUIER LAS PUEDE ENTENDER, ERGO, LAS PUEDES PROGRAMAR Y EL LENGUAJE LAS "ENTENDERA". Eso es especificamente, la labor que se hace en foros como este. Aqui NO DAMOS RESPUESTAS, no porque no queramos, sino porque muchas veces no podemos! (literalmente!) Porque? Porque NO ENTENDEMOS LA PREGUNTA! Si la entendemos, tendremos las respuesta, y al MISMO tiempo, la tendrias tu
__________________
El malabarista. |
#5
|
|||
|
|||
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
|
#6
|
|||
|
|||
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. |
#7
|
||||
|
||||
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. |
#8
|
||||
|
||||
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 |
|