Problema con Maestro-Detalle
 

Uso Dephi 7.0, FireBird 1.5, trabajo con componentes IBX 7.08

Tengo una aplicacion donde uno de mis formularios es maestro detalle, como ya es de suponer el maestro tiene una clave primary y la tabla detalle tiene una llave foranea al campo clave de la primera tabla.

Para ello utilizo dos IbDataSet con un solo IBtransacction, mi idea es aplicar un solo commit al transacction para mis dos tablas maestro detalle.

Pero veo el incoveniente de que para hacer un post a una fila de mi tabla detalle tiene que existir la fila en maestro.... :(

Pasos que he seguido:

Tabla Maestro
1.- Inserto un registro "insert"
2.- Ingreso los datos.
3.- Hago su respectivo "Post"
4.- Por ultimo su "Commit" linea que deseo evitar

Tabla Detalle
1.- Inserto un registro "insert"
2.- Ingreso los datos.
3.- Hago su respectivo "Post"
4.- Repito los pasos desde 1.- o continuo con el paso 5.-
5.- Por ultimo su "Commit"

Lo que necesito es añadir filas a la tabla detalle sin haber hecho un commit a la tabla maestro... esto quiere decir que cuando el usuario este conforme con sus datos ingresados tanto maestro y detalle presione el boton grabar y de esa forma se haria un solo commit. :D

Espero haber puesto bien estas lineas, lo tome de otra persona que planteo este mismo problema que tengo actualmente, por lo que lei las respuestas que les enviaron y en conclusión él mismo se resolvio el problema sin publicarlo. Agradezo mucho cualquier comentario.

Es fácil, no hagas el commit :D

No, a ver, tu puedes iniciar una transacción cuando quieras y terminarla cuando gustes. Todos los cambios sucedidos en la base de datos serán grabados a la vez en el commit o deshechados en el rollback y, durante la vida de la transacción, puedes ver los valores que toman dichos registros en cualquier momento

Así pues, no le veo el problema en hacer un solo commit al finalizar la entrada de datos del detalle (de hecho es lo que yo hayo :rolleyes: )

????
 

El problema que es, que si uso el commit cuando el usuario esta seguro de la información capturada(al final), me surge el siguiente problema y hago esto:
1.Abro la Captura de facturas,
2.Capturo la SERIE y su FOLIO(Maestro)
3.En el OnExit del EditFolio, busco si se encuentra el Maestro, SI lo encuentra muestra sus datos asi como sus hijos(Detalle).
SI NO LO ENCUENTRA Inserto un NUEVO registro al Maestro, le ingreso los 2 datos capturados por el usuario que son los campos llaves SERIE y FOLIO, al Insertarlo me doy cuenta en el Ib-Expert que no lo ha grabado todavía hasta que le doy un POST, pero si esta otro usuario dentro de la captura de Facturas con otro FOLIO distinto a este, me marca el siguiente Error:

Esta es la razón que no hago el Commit al finalizar la captura, pero si hago el Commit al principio, voy a tener un Serio problema con los FOLIOS de las Facturas, ¿porque? , porque supongamos que entran 2 usuarios con distintos
Folios el #10 y #11, ahora, Graba primero el segundo usuario que posee el Folio #11, pero el Folio Fiscal Impreso en la Factura es el #10, aqui es donde tendré el problema de FOLIOS ADELANTADOS.
Si me podría explicar usted en teoría como Solucionaría esto.
Espero me haya explicado... Gracias.

Help
 

Ya hice varias pruebas a continuación las mencionó:
1.-Puse un Proc. Almacenado en donde le mando como Parámetro de Entrada la Serie y el Folio de la Factura, en el cuerpo del Procedimiento Insertó y Actualizó tengo esto:

Código SQL [-]
  insert into tfac_facturas
  (TIPOMOV, FOLIO, AUTORIZO, AUTORPRE,  CLIENTE, CONCEPTO, COTIZADA, CREDCON, DESCTODOC,
  DESGLODOC, FECHAFAC,  IMPORFAC, IVADOC, ORDENCOMPRA, TASAIVA,VENCE, VENDEDOR, VIGENCIA)
  values
  (:SERIEX,:FOLIOX,Null,Null,Null,Null,Null,Null,Null,
   Null,Null,Null,Null,Null,Null,Null,Null,Null);
 
update TFAC_FACTURAS
set
  AUTORIZO = Null,
  AUTORPRE = Null,
  CLIENTE = Null,
  CONCEPTO = Null,
  COTIZADA = Null,
  CREDCON = Null,
  DESCTODOC = Null,
  DESGLODOC = Null,
  FECHAFAC = Null,
  IMPORFAC = Null,
  IVADOC = Null,
  ORDENCOMPRA = Null,
  TASAIVA = Null,
  VENCE = Null,
  VENDEDOR = Null,
  VIGENCIA = Null,
  TIPOMOV = :SERIEX,
  FOLIO = :FOLIOX
where
  TIPOMOV = :SERIEX and
  FOLIO = :FOLIOX;
  suspend;

Cuando mando a llamar este proc. almacenado desde delphi, reviso en el Ib-Expert si se encuentra el registro pero NO ESTA.

Todo me hace pensar que tengo que hacer un CommitRetaining antes de comenzar a capturar los Detalles, por lo que QUIERO EVITAR esto, porque de este modo, una vez aceptado la transacción al maestro, si el usuario quiere cancelar los cambios, tengo que borrar(Delete) el maestro con el detalle.

Y si el usuario decide guardar, tengo que revisar que FOLIO es, para compararlos con los otros FOLIOS que actualmente estan en uso para asignarle el FOLIO REAL CONSECUTIVO, para que no tenga problemas con el FOLIO Fiscalmente Impreso de la Factura.:(

FOLIO FISCAL=Es un Folio que ya viene impreso en el Papel de la Factura.
Si me explicó????...
De antemano Gracias por cualquier comentario.

Tenes aqui un serio problema de concepto. IB-Expert, isql o cualquier otra herramienta, correrá en el contexto de otra transacción distinta de la que ha insertado los datos... por lo tanto, no te mostrará el dato a menos que hagas commit. Si firebird no tuviera este comportamiento... y leyeramos datos inconsistentes... mejor nos regresamos a fox o paradox... ¿no te parece?

Pero el registro claro que existe, en el contexto de la transacción que lo está insertando. Podes comprobarlo lanzando un Select dentro de la misma aplicación (si tanto lo dudas...).

Por regla general, si el motor no te ha devuelto un error al hacer el insert (el post en el objeto si es un DataSet sin cached updates), el registro si estará en la base de datos.

Querer comprobarlo en ese momento... me parece paranoico.. :p

Hasta luego.

;)

????
 

Por lo que veo no me han entendido, Tengo 2 Edit's uno para la Serie y el otro para el Folio, ahora tengo que insertar un registro nuevo si no se encuentra la llave en la tabla, después de "insertar" llamo el "Post" y si no acepto la transacción para guardar el Maestro, me lanza un Error
"lock conflict on no wait transaction deadlock update conflicts with concurrent update"
De lo contrario, si acepto la transacción, me graba la SERIE y el FOLIO en el maestro y el detalle capturo los productos, todo parece que esta Correctamente bien, cada quien con su SERIE y FOLIO, pero el problema esta al imprimir, por ejemplo:
Si un usuario 1 captura una factura con el FOLIO #1 y el otro Usuario 2 con el FOLIO #2, y si resulta que el usuario 2 termina primero, al grabar manda el FOLIO# 2 en vez de mandar el FOLIO #1, aqui trato de reasignar el FOLIO del #2 al #1, pero no me deja porque es un campo que conforma la llave primaria, entonces tendría que BORRAR la Factura 2 para reasignarle el 1 y es un SHOW hacer esto, si no hay otra alternativa por lo que me estoy dando cuenta, pues ni modo.... Gracias ....

En este caso, creo que lo mas sano es que el Folio que se imprimirá, no forme parte de la llave primaria. Podes tener una llave primaria artificial, que simplemente asigne una secuencia a los campos, y que sea hasta el momento de imprimir que se asigne el folio de la operación.

Con el uso de indices, no creo que presente ningún problema para mantener la integridad y la facilidad de las consultas de la aplicación.

Hasta luego.

;)

oki
 

Muchas Gracias, y Muy buena idea.... voy a implementar su idea.

???
 

De hecho si funcionó, pero lo malo es que tengo que tenere otro campo para llevar un control de los Folios que se van a imprimir, siendo que me piden que el mismo FOLIO a imprimir sean iguales a los que muestra.
De antemano Gracias.