Métodos BeginTrans y CommitTrans
Mi problema es que no sé cuando ni como utilizar BIEN los
BeginTrans y CommitTrans (métodos de una conexión ADO).
Soy Técnico Superior en Desarrollo de Aplicaciones Informáticas y cuando estudiaba el ataque a bases de datos desde VB con ADO esto no se nos explicó bien.
Nos decían que ADO funciona de una manera asíncrona y que cuando haces un movenext o un update éste se queda ejecutándose y pasa el control a la siguiente instrucción en VB.
Es decir, que si hacíamos un movenext y en la siguiente instrucción consultábamos un campo del recordset podría pasar que el valor fuera el del registro anterior (vamos, que no le habría dado tiempo a hacer el movenext).
Para solucionar esto lo que "nos decían" que hiciéramos es que a la propiedad ActiveConnection del control ADO le asignáramos una conexión ADO conectada a la misma BD para luego utilizar los métodos BeginTrans y CommitTrans.
Un ejemplo de esto sería:
...
...
dim conn as new adodb.connection
set ado1.activeconnection=conn
Conn. Begintrans
Ado1.recordset.movenext
conn.committrans
...
...
De esta manera se "solucionaba" el problema de que la tecnología ADO funcionara de manera asíncrona.
¿Es todo esto cierto?
¿Existen métodos de los recordset que funcionan de manera asíncrona? ¿Quizás el update?
¿Cómo debo utilizar los BeginTrans y los CommitTrans? ¿Debería utilizarlos entre métodos de un recordset que funcionen de forma asíncrona (si es que existen) o debería utilizarlos con el sentido más amplio de transacción?
GRACIAS y espero que me resuelvan algunas de mis dudas ya que no son pocas!
BeginTrans y CommitTrans (métodos de una conexión ADO).
Soy Técnico Superior en Desarrollo de Aplicaciones Informáticas y cuando estudiaba el ataque a bases de datos desde VB con ADO esto no se nos explicó bien.
Nos decían que ADO funciona de una manera asíncrona y que cuando haces un movenext o un update éste se queda ejecutándose y pasa el control a la siguiente instrucción en VB.
Es decir, que si hacíamos un movenext y en la siguiente instrucción consultábamos un campo del recordset podría pasar que el valor fuera el del registro anterior (vamos, que no le habría dado tiempo a hacer el movenext).
Para solucionar esto lo que "nos decían" que hiciéramos es que a la propiedad ActiveConnection del control ADO le asignáramos una conexión ADO conectada a la misma BD para luego utilizar los métodos BeginTrans y CommitTrans.
Un ejemplo de esto sería:
...
...
dim conn as new adodb.connection
set ado1.activeconnection=conn
Conn. Begintrans
Ado1.recordset.movenext
conn.committrans
...
...
De esta manera se "solucionaba" el problema de que la tecnología ADO funcionara de manera asíncrona.
¿Es todo esto cierto?
¿Existen métodos de los recordset que funcionan de manera asíncrona? ¿Quizás el update?
¿Cómo debo utilizar los BeginTrans y los CommitTrans? ¿Debería utilizarlos entre métodos de un recordset que funcionen de forma asíncrona (si es que existen) o debería utilizarlos con el sentido más amplio de transacción?
GRACIAS y espero que me resuelvan algunas de mis dudas ya que no son pocas!
2 Respuestas
Respuesta de orande
1
Si, por lo menos yo lo hacia cuando utilizaba DAO, ya que la transacciones no se podían iniciar a través del objeto de la base de datos, sino del espacio de trabajo del DBEngine.
En ADO es lo mismo pero mejor hecho. Siempre que se haga una acción intenta englobarla en una transacción, te puedes evitar inconsistencias en la BBDD (sobretodo si hay varias conexiones sobre ella).
En ADO es lo mismo pero mejor hecho. Siempre que se haga una acción intenta englobarla en una transacción, te puedes evitar inconsistencias en la BBDD (sobretodo si hay varias conexiones sobre ella).
Entonces los uso para los update, delete y addnew, sin embargo, para métodos como filter, requery, movenext, moveprevious... ¿debería utilizarlos?
Vamos a ver, en principio y basándome en mi experiencia lo asíncrono en ADO no viene omitido, solo ocurre cuando tu lo pides explícitamente.
Es decir, el movimiento del registro no debería ser asíncrono nunca: o esta el registro al que quieres acceder o te dará un error en las comunicaciones al no poder acceder a los datos y tener el "registro activo" (su boormark) sin apuntar a ningún registro.
Las transacciones se deben usar cuando utilices alguna acción (inserción, edición o eliminación), pero no en una consulta (cargas el proceso para nada).
El objetivo de la transacción es poder dar vuelta a atrás a un estado de la BBDD si hay algún error o, si todo ha ido bien, "fijar" los datos de forma permanente.
El uso de la ejecución asíncrona (es un parámetro, adExecuteAsync, del método Execute) se usa cuando quieres que la acción continué en tu aplicación, aunque no se haya completado todas las acciones en la BBDD y el gestor este ocupado (muy útil para evitar largos tiempos de espera).
Sobre el uso de las transacciones, intenta que en el mismo procedimiento se inicie y se cierre, de una manera u otra, la transacción. Asegurate siempre de que, si ocurre un error, la transacción se deshaga:
Public Sub EjecutarSQL(Byval SQL as String)
Dim InTrans as boolean
On error goto TratarError
conn.BeginTrans: InTrans = True
conn.Execute SQL
conn.CommitTrans: InTrans = False
TratarError:
If InTrans Then conn.RollBackTrans
If Err.number <> 0 Then
MsgBox Err.Description, vbExclamation, Err.Source
Err.Clear
End If
End Sub
Es decir, el movimiento del registro no debería ser asíncrono nunca: o esta el registro al que quieres acceder o te dará un error en las comunicaciones al no poder acceder a los datos y tener el "registro activo" (su boormark) sin apuntar a ningún registro.
Las transacciones se deben usar cuando utilices alguna acción (inserción, edición o eliminación), pero no en una consulta (cargas el proceso para nada).
El objetivo de la transacción es poder dar vuelta a atrás a un estado de la BBDD si hay algún error o, si todo ha ido bien, "fijar" los datos de forma permanente.
El uso de la ejecución asíncrona (es un parámetro, adExecuteAsync, del método Execute) se usa cuando quieres que la acción continué en tu aplicación, aunque no se haya completado todas las acciones en la BBDD y el gestor este ocupado (muy útil para evitar largos tiempos de espera).
Sobre el uso de las transacciones, intenta que en el mismo procedimiento se inicie y se cierre, de una manera u otra, la transacción. Asegurate siempre de que, si ocurre un error, la transacción se deshaga:
Public Sub EjecutarSQL(Byval SQL as String)
Dim InTrans as boolean
On error goto TratarError
conn.BeginTrans: InTrans = True
conn.Execute SQL
conn.CommitTrans: InTrans = False
TratarError:
If InTrans Then conn.RollBackTrans
If Err.number <> 0 Then
MsgBox Err.Description, vbExclamation, Err.Source
Err.Clear
End If
End Sub
En primer lugar gracias por interesarte por esta pregunta.
Quisiera que me respondieras a una duda que me ha surgido tras leer tu respuesta:
Cuándo dices que se deben utilizar transacciones en las acciones de inserción, borrado y actualización supongo que te refieres a cuando utilizas el método execute tanto de una conexión como de un comando, pero, ¿debería utilizar el gestor de transacciones si las inserciones, borrado y modificaciones las hago a través de métodos de recordset addnew, delete y update?
Gracias!
Quisiera que me respondieras a una duda que me ha surgido tras leer tu respuesta:
Cuándo dices que se deben utilizar transacciones en las acciones de inserción, borrado y actualización supongo que te refieres a cuando utilizas el método execute tanto de una conexión como de un comando, pero, ¿debería utilizar el gestor de transacciones si las inserciones, borrado y modificaciones las hago a través de métodos de recordset addnew, delete y update?
Gracias!
No, no vale la pena que los uses si no es para una acción.
Respuesta de ingariel
1
El beginstrans y el commit, se utilizan con ADO, para asegurar la integridad de los datos, al hacer moverte entre los registros no hay problema, ya que no afectas los valores de los campos de la base de datos, debes utilizar estos métodos, si y solo si, vas a modificar la base de datos, por lo tanto deberás abrir una transacción(BeginTrans) al iniciar un evento de modificación de la base de datos(insert, delete, update), y terminarla, hasta después de realizar todas las modificaciones(committrans).. esto hace que si alguna instrucción falla, no se realiza ningún cambio en la base de datos.. si tienes más duda, házmelo saber.. sale.. nos vemos