Hola,
Cita:
Posteado originalmente por LBriceno
En realidad el problema que se presenta es un problema de actualización "deadlock-update conflicts with concurrent update", y este se produce cuando un usuario intenta modificar un registro
que fué modificado por otra aplicación,
|
Bien, hasta ahora es el comportamiento normal que debe tener el servidor.
Cita:
Posteado originalmente por LBriceno
sin haber abierto desde la app. ninguna transacción,
|
¡Oh!, sí que la abre, sí; créeme.
Cita:
Posteado originalmente por LBriceno
es decir, las transacciones que genera el servidor (arq. multigeneracional)
|
Bueno, como te comenté antes, es el cliente el que arranca la transacción (a través de una llamada a la función del API:
isc_start_transaction o
isc_start_multiple), no el servidor. Cuando hablamos de transacciones implícitas, nos referimos a transacciones que arranca el cliente automáticamente. En tu caso a través de los componentes ADO.
Cita:
Posteado originalmente por LBriceno
no se cierran una vez realizados los cambios, o bien, cada conexión genera una transacción antes de siquiera leer algun registro.
|
Consejo: acostúmbrate a controlar tú explícitamente la apartura y cierre (commit o rollback) de las transacciones. En el caso concreto de ADO no sé cómo será, ya que no lo utilizo, pero con seguridad habrá algún método
Start o
StartTransaction y
Commit y
Rollback.
Cita:
Posteado originalmente por LBriceno
Pregunta: ¿es necesario que las aplicaciones se conecten a la BD con distinto nombre de usuario?
|
No, incluso desde una misma aplicación pueden abrirse varias conexiones contra el servidor utilizando el mismo user/password.
Saludos.