FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Es fácil, no hagas el commit
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 ) |
#2
|
||||
|
||||
????
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: Código:
lock conflict on no wait transaction deadlock update conflicts with concurrent update 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. Última edición por AGAG4 fecha: 10-09-2004 a las 16:27:38. Razón: Corrección |
#3
|
||||
|
||||
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:
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. |
#4
|
||||
|
||||
Cita:
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.. Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#5
|
||||
|
||||
????
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 .... |
#6
|
||||
|
||||
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.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#7
|
||||
|
||||
oki
Muchas Gracias, y Muy buena idea.... voy a implementar su idea.
|
|
|
|