Problema al grabar un Master/Detail el detalle no se graba...

[Ricardojosep]

Gracias guillotemarc, ahora voy a poner los errores en pantalla para ver que puede estar pasando, cualquier cosa vuelvo con el hilo.

Muchas gracias a todos!!

Saludos!!

[Ricardojosep]

Hola de nuevo, sigo con el problema, pero ahora hice lo que me dijo guillotemarc y grabe los errores en un archivo de texto... el primer error que me aparece es: -901 Lock conflict on no wait transaction. Este error se produce en un Procedimiento Almacenado, que es el que se encarga de actualizar el stock. El problema esta que cuando los operadores cargan una compra, para incrementar el stock y después de un corto tiempo, mas o menos 30 segundo, se hace una venta y produce este error. Mi gran pregunta es: ¿Porque se produce un bloqueo si la primera transacción (compra) finaliza primero, y después se inicia la otra...?

En fin, de todas maneras, muchas gracias por la ayuda que me dieron!!

Saludos!!!

Ricardo

[Casimiro Notevi]

Habría que ver ese código, cuando haces commit y eso... pero en principio puedes cambiar las transacciones a "no wait".

Yo siempre lo pongo así:

write
nowait
rec_version
read_committed

[Ricardojosep]

Hola Casimiro, voy a probar de cambiar la transacción a no wait, pero a mi me resulta muy extraño... porque se supone que la transacción finaliza y despues de un tiempo comienza la otra... y lo peor de todo es que le dice al operador que todo esta bien, y no le muestra el error, aclaro, yo guardo el mensaje de error en un archivo de texto, pero muestro un error personalizado en pantalla, y ese error personalizado no se ve...

Muchas gracias casimiro!!!

Saludos!!

[guillotmarc]

Hola.

El mensaje de error es bastante claro, desde una transacción se intenta modificar un registro bloqueado por una modificación no confirmada en otra transacción aún activa.

Es un papelón, pero te toca revisar todo tu código, puesto que alguna transacción queda abierta. Recuerda que el conflicto no tiene porqué estar solo la tabla de stocks (aunque parece lo más lógico), puede ser cualquier tabla que intenten modificar ambas transacciones (como la de Logs, ...).

NOTA: Las transacciones tienen que ser lo más cortas posibles, abres la transacción, haces la modificación y la cierras enseguida. Por esto me gusta utilizar ClientDatasets, nunca tengo transacciones abiertas en mi programas, ni siquiera para mostrar datos en pantalla : abro la transacción, cargo el ClientDataset y cierro la transacción.

Saludos.

[guillotmarc]

Por cierto, puedes probar una chapuza para salir del paso mientras lo arreglas bien.

Cambia el nivel de aislamiento de la transacción a READ UNCOMMITED (no estoy seguro de si Firebird acepta este nivel de aislamiento, pero como forma parte del estándar, puedes probar).

En este nivel de aislamiento no hay bloqueos, aunque una transacción no haya terminado sus cambios ya son visibles desde las otras transacciones. En cierta manera es como trabajar sin transacciones, lo cual evidentemente conlleva sus propios problemas.

Yo solo lo utilizaría como un parche temporal.

[Ricardojosep]

Hola guillotmarc, Estuve viendo todo el procedimiento de grabacion... realmente es muy simple y esta asegurado el commit para el cierre de la transacción. En fin, voy a seguir viendo cual puede ser el error, y voy a parchar el sistema con tus sugerencias!

Ahh otra cosa, la actualizacion del stock lo hago con un procedimiento almacenado, crees que si lo hago desde el trigger de grabacion de compras me crearia algun inconveniente mas?

Gracias por todo!

Saludos!!

Ricardo.