FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
#2
|
||||
|
||||
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" |
#3
|
||||
|
||||
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. |
#4
|
|||
|
|||
Cita:
saludos |
#5
|
||||
|
||||
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. |
#6
|
|||
|
|||
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 08:24:13 |
lock conflict on no wait transaction | berna | Firebird e Interbase | 1 | 02-08-2012 21:54:50 |
lock conflict on no wait transaction deadlock | Chogo | Firebird e Interbase | 1 | 07-07-2010 17:44:45 |
Error Lock conflict al momento de Delete | Addicto | Firebird e Interbase | 2 | 04-07-2008 16:02:39 |
Lock conflict on no wait transaction | gorsan | Conexión con bases de datos | 2 | 08-08-2007 09:47:56 |
|