Que tan confiable es MySQL

[[Al González]]

Empezado por darkerbyte

[...]tengo una tabla de productos con un campo llamado 'Existencia'

Código SQL [-]
START TRANSACTION;
INSERT INTO ventas(idVenta, fecha, hora, cliente, vendedor, turno, descuento)
                 VALUES (16, '2016-06-08', '22:19:12', 1, 2, 1, 0.00);
INSERT INTO ventas_partidas(idVenta, idProd, cantidad, precio_compra, precio_venta)
                  VALUES(16, 'PDE', 3.00, 29.00, 35.00);
UPDATE productos SET almacen=almacen-3.00 WHERE clave='PDE';   -- Esta instrucción es donde esta mi duda

1. ¿El campo se llama realmente Existencia o almacen?

2. Te recomiendo prescindir de valores literales en sentencias SQL de aplicaciones que no son de uso interno o de pruebas. Es mejor y más seguro usar parámetros ("...Values (..., :Cantidad..."). Quizá en la computadora del cliente 3.00 no sea lo que tú crees que es (configuración regional).

3. ¿Existe la remota posibilidad de que tengas dos productos con la misma clave?

4. ¿Tendrás algún disparador (trigger) involucrado con esas tablas y que no estés observando?

5. ¿Las diferencias inesperadas que se presentan son consistentes o varían sin sentido? ¿El error se presenta bajo un patrón común respecto a las cantidades que debería haber y las que hay?

Saludos misteriosos.

[darkerbyte]

Gracias Al González.

Siempre es bueno repasar lo básico, no es la primera vez que me pasa estar haciendo algo mal. Respecto a lo que me comentas

1. ¿El campo se llama realmente Existencia o almacen?
El campo se llama almancén, y lo uso para llevar la existencia. Me equivoqué al formular la pregunta.

2. Te recomiendo prescindir de valores literales en sentencias SQL de aplicaciones que no son de uso interno o de pruebas. Es mejor y más seguro usar parámetros ("...Values (..., :Cantidad..."). Quizá en la computadora del cliente 3.00 no sea lo que tú crees que es (configuración regional).
Aprecio el consejo voy a hacer los cambios para que sea por parámetros

3. ¿Existe la remota posibilidad de que tengas dos productos con la misma clave?
No, en la tabla de Productos la clave es llave primaria y el sistema hace una revisión antes de modificar o insertar nuevo producto.

4. ¿Tendrás algún disparador (trigger) involucrado con esas tablas y que no estés observando?
Gracias ya revisé. No tengo de momento triggers en esta parte.

5. ¿Las diferencias inesperadas que se presentan son consistentes o varían sin sentido? ¿El error se presenta bajo un patrón común respecto a las cantidades que debería haber y las que hay?
Varían sin sentido.


Por eso mi pregunta sobre la confiabilidad de MySQL. De hecho otro cliente tenía un problema parecido. A este cliente cuando hacía sus ventas en sus tickets (Impresión en RAW) y notas (hechas con QuickReport) los precios salían distintos a los que tenemos guardados en el sistema. Me volví loco haciendo pruebas, depurando una y otra vez las rutinas del programa. Ya desesperados le dimos formato a sus computadoras y problema solucionado. Aun sigo sin poder explicarme que fue lo que estaba pasando.

De momento estoy haciendo lo del Log que me han sugerido, estoy también haciendo revisión en las rutinas. Por último mi tirada es hacer pruebas para cambiar el servidor del 5.1 a 5.7.
Bueno, les mantendré informados que pasa. Gracias a todos por su tiempo y sus sugerencias

[bitbow]

La realidad es que en mi experiencia personal MySql aunque recomendable para sistemas web, en sistemas de escritorio corre lento por lo que he optado por firebird y firebird llegando a usarlo solo cuando el cliente así lo requiere, además de que me he topado con que hay errores que no gestiona adecuadamente como que este mal la sintaxis y aún así compile los procedimientos (igual y es la versión), es verdad que es una base robusta con muchas funcionalidades en cuanto a seguridad, librerías, tipos de datos, etc pero prefiero firebird.

[mamcx]

Empezado por darkerbyte

Varían sin sentido.

Podrias dar un ejemplo de como varian? Como era antes (bueno) como es despues(malo) y como deberia haber sido?

[darkerbyte]

Mamcx

El cliente me reporta que hacen una venta y los productos que ha vendido los cuales deberían haber sido descontados siguen apareciendo en existencia.
Por eso comenté que tenía mi duda al respecto con esta instrucción:

UPDATE productos SET almacen=almacen-3.00 WHERE clave='PDE'; --En este caso se vendieron 3 pzas del producto 'PDE'

Para cada producto que se vende se inserta la partida en la tabla de "ventas_det" y se hace el desconteo respectivo en la tabla de productos. Después de revisar el kardex veo que efectivamente tengo existencia de más del producto.
Esto es muy extraño porque el algoritmo genera las dos consultas, tanto para insertar como para descontar y lo hace dentro de una transacción y he probado cientos de veces, sin exagerar quizá miles de veces el procedimiento, tranzando paso a paso.
Igual al cliente no se lo hace en todas las ventas, ni en todos los productos.
He cuidado que las claves de los productos de los clientes no tengan símbolos especiales (comillas, asteriscos, etc). Para que no pudieran dar alguna falla en la consulta por el propio lenguaje de MySQL

Creo que es cosa del Chamuco, como decimos por acá.

[Casimiro Noteví]

Empezado por darkerbyte

UPDATE productos SET almacen=almacen-3.00 WHERE clave='PDE'; --En este caso se vendieron 3 pzas del producto 'PDE'

Eso no son 3 piezas, sino 3.00

[mamcx]

Conceptualmente es el problema que resuelve la contabilidad doble: Si no se conserva la historia y flujo de las transacciones se pueden generar errores (o fraudes).

El problema de fondo es que el manejo del estado de los datos normales en forma CRUD es *destructivo* y no hay manera de saber como se llego al resultado actual. Para un inventario, al igual que un libro contable - de hecho, un inventario es una forma especial de contabilidad- es mas solido usar un diseño inmutable (donde no se sobreescribe sino que se agregan los resultados).

Osea, un log.

Es mejor que el inventario sea asi:

Feb1 - Ref:ABC BUY = Qty:1, Value:$10
Feb2 - Ref:ABC SELL = Qty:1, Value:$15
Feb3 - Ref:ABC BUY = Qty:10, Value:$20
Feb3 - Ref:ABC TRANSFER = Qty:10, Value:$20 TO Store: 2

Nota: Se registra luego de hacer las validaciones. Por eso, si no se permiten vender por debajo del stock, no saldran lineas con inventarios negativos. Osea, se registra solo un hecho real y concreto (en el pasado) y no lo que se va a hacer y que *puede* ser rechazado por la logica del negocio.


Y usar la tabla de inventarios como "cache" con el valor actual del stock (Asi que obvio tienes un campo Stock actual). Asi, teniendo la historia en forma de log, puedes tener claro como se movio el flujo del inventario.

Entonces, si hay un problema con un producto, puedes consultar tu log y ver en que momento se genero el problema.

[darkerbyte]

Ya hice la complementación para generar un archivo log. Para cada procedimiento el programa guarda lo que el usuario tiene en pantalla y las consultas que el sistema envía al servidor. Ahora a dar un poco de tiempo para empezar a rastrear los archivos

[darkerbyte]

Usando la idea de Mamcx agregué a cada procedimiento que "mete mano" a la base de datos un log de la información que tengo en pantalla junto con la consulta que está enviando a MySQL para serciorarme que no fuese un error de programación mío.

También implementé en el sistema un método para capturar el estado del inventario (screenshot) que almacena para cada producto
la existencia en cada sucursal junto con el costo del producto. Por supuesto se guarda también la fecha y hora de captura.

Mis clientes volvieron a tener problemas con las existencias de su inventario.
El día 4 estuve haciendo unas pruebas, hice una captura de inventario, el día 5 se registró un movimiento para dos productos
fue una única venta, en el archivo log esto es lo que tenía en pantalla:



Cantidad Clave Descripción Precio Unitario, importe

0.50 ; 520100106; ULTRAFONDO TRANSP. CATALIZABLE GRANEL; Menudeo; 85.50; 42.75 ;
0.50 ; 521101806; CATALIZADOR AL 100% P/ULTRAFONDO GRANEL; Menudeo; 84.50; 42.25 ;

Y aquí lo que se mandó al servidor

Código SQL [-]
START TRANSACTION;
INSERT INTO ventas VALUES (1,8126, '2016-10-05', '17:42:48', 1, 3,282,'',0, 0, 0, 0);
INSERT INTO pedidos VALUES(1,8126,'520100106',0,0.50,1,65.96,85.50);
INSERT INTO pedidos VALUES(1,8126,'521101806',1,0.50,1,65.01,84.50);
UPDATE productos set suc1=suc1-0.50 WHERE clave='520100106';
UPDATE productos set suc1=suc1-0.50 WHERE clave='521101806';
Commit;

El punto es este, pueden ver que en las dos ultimas lineas se resta de la existencia en la sucursal 1 [suc1(decimal(8,2)] la cantidad vendida 0.5
En el screenshot que hice de mi inventario tenía 9.70 piezas y después de esta venta tengo una existencia de 6.20 en el producto "520100106, ULTRAFONDO TRANSP. CATALIZABLE GRANEL"

Escribo el resultado de mis pruebas por si alguien más a futuro pasa por una situación similar. Versión de MySQL la 5.1.33


Voy a probar con otra versión de MySQL porque ya me volví loco haciendo debugs y probando cientos de veces el codigo fuente
o quizá me cambie a Firebird