FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Problema con Lock conflict
Hola, tengo un programa de facturas, el primero hecho con firebird 2.5 y los IBX de Delphi 7 y me da este error en distintas operaciones (borrar, ingresar, modificar), al parecer un usuario deja la tabla o una transacciòn colgada, que opinan de cual puede ser el motivo del mensaje ?
Saludos |
#2
|
||||
|
||||
Nunca había visto un deadlock con firebird, tendrían que darte un premio
Solucionar esto puede ser fácil o muy, muy difícil. Todo depende de cómo hayas programado el sistema. Para empezar, ¿qué parámetros tienes en el TIBTransaction?
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#3
|
||||
|
||||
Cita:
acá podrás mirar porque salen los bloqueos en firebird. La ídea es que compare con su transacción y mire porque pasa. Por cierto, algo que me pasaba antes con respecto a estos bloqueos era que usaba componentes del tipo DBEdit o similares, entonces por decir algo alguien empezaba a escribir en un dbEdit y acá arrancaba una transacción y después de mucho rato seguía abierta y sin un commit a la vista. Luego desde otro equipo alguien más trataba de guardar algo pero en el equipo original había aún una transacción esperando a realizar ya fuera commit o rollback... Lo mejor es evitar eso y hacer transacciones lo más pequeñas posibles. ejemplo
__________________
"Como pasa el tiempo..... ayer se escribe sin H y hoy con H" |
#4
|
|||
|
|||
Cita:
|
#5
|
||||
|
||||
[RONPABLO], si tiene bien configurado los parámetros del TIBTransaction, él se encarga de las transacciones, no hay que preocuparse de nada.
No es necesario iniciar/confirmar una transacción, salvo que sea "larga" y tenga implicada varias tablas que deseemos que tengan "consistencia". Para ello se usaría de forma similar a como has descrito.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal Última edición por Casimiro Notevi fecha: 12-11-2015 a las 22:16:18. |
#6
|
||||
|
||||
Botón derecho en el componente y mira los parámetros.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#7
|
|||
|
|||
Cita:
MasterDb.ReqmtoMas.Post; Try Masterdb.IBTrsc.CommitRetaining; ShowMessage('! REQUERIMIENTO GRABADO CORRECTAMENTE !'); Except MasterDb.ReqmtoMas.Cancel; Masterdb.IBTrsc.RollbackRetaining; ShowMessage('Se produjo un error y no se grabarón los datos'); end; |
#8
|
||||
|
||||
Recuerda poner los tags al código fuente, ejemplo:
Gracias
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#9
|
|||
|
|||
#10
|
||||
|
||||
ok, ahora con esos parámetros compara con el link que envié anteriormente y mira... así por encima lo que vi era que el nowait es uno de los que genera el deadLock, allá ene se enlace lo explican que va a pasar.
__________________
"Como pasa el tiempo..... ayer se escribe sin H y hoy con H" |
#11
|
||||
|
||||
Hace falta más información, ¿usas más de un tibtransaction? ¿qué código está usando? etc.
Yo siempre he usado esos parámetros, desde 1998, y nunca he visto un deadlock.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#12
|
|||
|
|||
Cita:
saludos |
#13
|
||||
|
||||
Yo también prefiero no usar controles DB, mejor hacerlos por Edits normales. Así la transacción empieza cuando el usuario pulsa el botón de aceptar y sabemos que terminará enseguida.
O eso, o usar ClientDatasets... un poco más latoso al principio de entender, pero puedes usar DBEdits. Tienes disponibles todos los eventos de esos controles DB. La transacción no empieza cuando editas un DBEdit. El botón aceptar se convierte en un ClientDataset1.ApplyUpdates; y ahí se aplican todos los cambios de golpe. Para controlar los errores de 2 usuarios concurrentes, se usa File -> new -> Other -> Dialogs -> Reconcile Error Dialog Es una ventana que le aparecerá al segundo usuario que intenta grabar el mismo registro que otro usuario se adelantó a grabar. Le dice qué campos tienen conflictos y los valores de los 2 usuarios. Además le pide al segundo usuario que resuelva el conflicto: - guardar los datos que introdujo el primer usuario - guardar los datos que ha introducido él mismo. Saludos!
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#14
|
|||
|
|||
Al final el problema era que había un Update del correlativo que quedaba fuera del Commit cuando se cancelaba el ingreso y quedaba la transacción abierta y si venia otro usuario a ocupar la misma tabla provocaba que apareciera el error.
De todas maneras cambie de NoWait a Wait la configuración de las transacciones. Ahora lei que hay una tabla que lleva el registros de las transacciones y supongo que esa transacción muerta queda almacenada, al hacer un backup y restore se limpia dicho registro ? Saludos y gracias por sus aportes. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Lock conflict on no Wait transaction Deadlock | gorsan | Conexión con bases de datos | 3 | 12-03-2015 09:24:13 |
lock conflict on no wait transaction | berna | Firebird e Interbase | 1 | 02-08-2012 22:54:50 |
lock conflict on no wait transaction deadlock | Chogo | Firebird e Interbase | 1 | 07-07-2010 18:44:45 |
Error Lock conflict al momento de Delete | Addicto | Firebird e Interbase | 2 | 04-07-2008 17:02:39 |
Lock conflict on no wait transaction | gorsan | Conexión con bases de datos | 2 | 08-08-2007 10:47:56 |
|