Como guardar Maestro Detalles entorno de red

[DamianG]

Hola mi consulta es la siguiente: tengo una tabla maestro (t1) y otra detalles (t2), como seria la forma correcta de guardar la informacion?

Ejemplo 1
---------
insert into t1 (c1, c2) values .....
try
commit
except end

insert into t2 (c1, c2, c3) values .....
try
commit
except end

o

Ejemplo 2
---------

try

insert into t1 (c1, c2) values .....
insert into t2 (c1, c2, c3) values .....
commit

except end

En un prinicipio lo hacia como en el ejemplo 2, pasa que a veces me daba error de transacciones pendientes en un entorno de red... lo cambie por el ejemplo 2 y todo bien, pero no estoy seguro de estar haciendo las cosas correctamente.

Gracias

[guillotmarc]

La forma correcta de hacerlo es la 2), así si hay algún problema se cancela la transacción con lo que no se guarda ningún registro, ni en el maestro ni en el detalle (En cambio con la opción 1) nos podemos encontrar facilmente con que hemos guardado el maestro, pero no hemos podido guardar los detalles, con lo que tenemos información incompleta e incoherente en la base de datos).

En todo caso la opción 1) tampoco te debería dar esos problemas de transacciones pendientes. Si quieres buscar la causa deberías darnos más información : mensaje de error exacto, componentes usados, código Delphi real, etc. ...

[DamianG]

Los componentes utilizados son los de Interbase, para las tablas utilizo tibquery.

El error que sale cada tanto es: (estando en red)

lock conflict on no wait transaction
deadlock
update conflicts with concurrent update
concurrent transaction number is 83114.

El código:

tengo las tablas FACVTA (FACTURAS), DETFAC (DETALLES DE PRODUCTOS VENDIDOS, ARTICULOS (PARA ACTUALIZAR LAS CANTIDADES)

---- guardo encabezado
insert into factura_encabezado (...) values ...
execsql;

---- guardo detalles de facturas y actualizo cantidades

Recorro una tabla temporal y voy insertando en los datalles los productos vendidos y actualizando cantidades

first
while ... not eof do
begin

insert into factura_detalles (...) values ....
execsql;

//aca mismo actualizo las cantidad de la tabla articulos

update articulos set cantid = cantid + .... where codart = facturas_detalles.codart
execsql;

next
end //while

tablascommit; (Aqui surge el error cada tanto)

//PROCDIMIENTO TABLASCOMMIT QUE USO
procedure tablascommit;
begin
try
datafb.IBTransaction1.CommitRetaining;
except
datafb.IBTransaction1.RollbackRetaining;
end;
end;

sino se entiende pongo el codigo real, no lo puse por lo extenso, gracias!

[guillotmarc]

Empezado por DamianG

lock conflict on no wait transaction
deadlock
update conflicts with concurrent update
concurrent transaction number is 83114.

Este error es un deadlock, un bloqueo, no es un problema de tener transacciones pendientes, es un problema de que dos transacciones quieren modificar el mismo registro (pueden ser en la misma máquina, y por lo tanto tu programa mantiene dos transacciones abiertas que modifican las mismas tablas, o bien puede ser que en dos máquinas distintas intentan modificar el mismo registro).

NOTA: Los triggers también cuentan. De manera que si al añadir productos vendidos, vas actualizando su stock. Entonces dos maquinas distintas, aunque den de alta ventas distintas, van a intentar modificar el stock del mismo producto, y vas a tener un bloqueo en ese registro.

Saludos.

[rastafarey]

Puedes crear una vista actualizable que trbajo sobre ambas tablas y de esa manera pueder verificar el error de bloque. Aunque es muy raro que firebird te de error de bloque ya usa versionado de registros. Debes estar cometiendo un error y no lo estas notando. Has la prueba con una vista actualizable.

[guillotmarc]

Empezado por rastafarey

Puedes crear una vista actualizable que trbajo sobre ambas tablas y de esa manera pueder verificar el error de bloque. Aunque es muy raro que firebird te de error de bloque ya usa versionado de registros. Debes estar cometiendo un error y no lo estas notando. Has la prueba con una vista actualizable.

En realidad no es nada raro.

Coge un registro, modifícalo con un UPDATE pero no termines la transacción.

Ahora en otro equipo intenta modificar el mismo registro. No vas a poder hasta que el primer equipo no finalice esa transacción. (Por eso me gusta trabajar con ClientDatasets, nunca se dejan transacciones abiertas, y cuando se hacen cambios en la b.b.d.d. las transacciones duran el mínimo tiempo posible. Cuanto más cortas sean tus transacciones menos posibilidades tendrás de encontrarte bloqueos).

NOTA: El sistema de versiones son para las lecturas.