Control de errores y Bloqueos RDO con Access
Otra vez mmaynard, como siempre vuelvo a necesitar ayuda. Me gustaría si es posible que me explicaras(con código) como puedo hacer el control de errores y bloqueos para mi aplicación multiusuario, es decir Utilizo la Conexión RDO Contra access y necesito saber a la Hora de Realizar un UPDATE como puedo bloquear la Fila para que desde otro ordenador no me pisen los datos que estoy modificando, y que tipo de errores se producirán en el equipo que intenta pisar esos datos, y como controlarlos para mostrar al usuario un mensaje cada vez que ocurran.
1 Respuesta
Respuesta de mmaynard
1
Primero decirte que no he utilizado RDO en la vida porque cuando empecé a programar el acceso a datos ya estaba bastante avanzado del DAO y de él pasé directamente a ADO.
En cualquiera de los casos, voy a contarte cómo procedo yo a la hora de solucionar problemas de bloqueos y actualizaciones de registros:
En principio, todos los objetos de acceso a datos te van a ofrecer la configuración de las opciones de los cursores, tanto para la apertura del recordset como para el bloqueo para el resto de usuarios.
Se supone que esto debería ser una buena herramienta en la que confiar a la hora de llevar a cabo una actualización pero, aún así, yo tengo que reconocerte que no me fío demasiado y actúo de la siguiente manera:
Si no es TOTALMENTE INDISPENSABLE procuro no tener nunca abierto ningún recordset. Es decir, lo abro sólo para la recuperación de los datos, para "pintarlos" en la pantalla (por supuesto no utilizo nunca controles que requieran el recordset abierto estilo datagrid o boungrid, sino que uso mucho, por ejemplo, el ListView o controles que me hago yo y me permiten tener el recordset cerrado) y lo cierro.
A la hora de llevar a cabo actualizaciones, nuevos registros o eliminaciones, procuro tirar de la conexión y el Transac SQL y, si no hay más narices, objetos recordset a nivel de procedimientos que, en cuanto llamo al Update, procuro cerrarlos.
¿Qué requiere esta manera de proceder? Tener siempre controlados los registros que voy a actualizar y actualizar siempre en última instancia los datos de las columnas clave. Por ejemplo, ahora mismo estoy desarrollando una aplicación de facturación. Una de las tablas tiene como clave principal el número de factura que ha de ser correlativo. Pues bien, el usuario mete toda la información en una serie de cuadros de texto que no están vinculados con ningún origen de datos y, cuando llama al método actualizar, es entonces cuando abro la tabla de facturas, tomo el último número de factura, le sumo uno y procedo a llamar a un INSERT INTO con ese nuevo número de factura. Tengo comprobado que no hay errores en el resto de campo y procedo de la siguiente manera: ya que todo lo demás está correcto, en caso de que se genere un error (On Error Goto) será porque estoy duplicando la clave (lo que sólo podría suceder, muy improbablemente, si otro usuario ha dado exactamente en el MISMO instante de tiempo al botón de actualizar) Entonces sumo otra unidad al número de factura y, en caso de que volviera a dar error de duplicidad de clave (totalmente improbalble) volveríamos al error y le sumaríamos otra unidad. Así hasta que no se diera error. Ahora, como el usuario no tiene ni idea del número de factura que acaba de introducir (porque no lo ha decidido él, sino la aplicación y en segundo plano) yo, personalmente, le devuelvo un MsgBox con " se ha dado de alta el número de factura XXXXXX " (por avisarle de alguna manera)
Es decir, si sólo abres el recordset en los momentos estrictamente necesarios para las actualizaciones, juegas con la ley de probabilidad a tu favor y, en caso de que se dieran errores, solucionarlos, como ves, es sencillo (independientemente del tipo de conexión que utilices)
Ahora, te comento, esta manera de proceder funciona cuando estás desarrollando una aplicación "contra access" (o contra cualquier otro proveedor de datos) pero no es viable (o es poco operativa) si la aplicación es "en access" (es decir, una aplicación VB, por ejemplo, contra access)
Si te das cuenta no te he comentado nada de RDO ni te he pasado una línea de código, lo siento, pero es que como te comento, no he utilizado RDO en la vida.
En cualquiera de los casos, voy a contarte cómo procedo yo a la hora de solucionar problemas de bloqueos y actualizaciones de registros:
En principio, todos los objetos de acceso a datos te van a ofrecer la configuración de las opciones de los cursores, tanto para la apertura del recordset como para el bloqueo para el resto de usuarios.
Se supone que esto debería ser una buena herramienta en la que confiar a la hora de llevar a cabo una actualización pero, aún así, yo tengo que reconocerte que no me fío demasiado y actúo de la siguiente manera:
Si no es TOTALMENTE INDISPENSABLE procuro no tener nunca abierto ningún recordset. Es decir, lo abro sólo para la recuperación de los datos, para "pintarlos" en la pantalla (por supuesto no utilizo nunca controles que requieran el recordset abierto estilo datagrid o boungrid, sino que uso mucho, por ejemplo, el ListView o controles que me hago yo y me permiten tener el recordset cerrado) y lo cierro.
A la hora de llevar a cabo actualizaciones, nuevos registros o eliminaciones, procuro tirar de la conexión y el Transac SQL y, si no hay más narices, objetos recordset a nivel de procedimientos que, en cuanto llamo al Update, procuro cerrarlos.
¿Qué requiere esta manera de proceder? Tener siempre controlados los registros que voy a actualizar y actualizar siempre en última instancia los datos de las columnas clave. Por ejemplo, ahora mismo estoy desarrollando una aplicación de facturación. Una de las tablas tiene como clave principal el número de factura que ha de ser correlativo. Pues bien, el usuario mete toda la información en una serie de cuadros de texto que no están vinculados con ningún origen de datos y, cuando llama al método actualizar, es entonces cuando abro la tabla de facturas, tomo el último número de factura, le sumo uno y procedo a llamar a un INSERT INTO con ese nuevo número de factura. Tengo comprobado que no hay errores en el resto de campo y procedo de la siguiente manera: ya que todo lo demás está correcto, en caso de que se genere un error (On Error Goto) será porque estoy duplicando la clave (lo que sólo podría suceder, muy improbablemente, si otro usuario ha dado exactamente en el MISMO instante de tiempo al botón de actualizar) Entonces sumo otra unidad al número de factura y, en caso de que volviera a dar error de duplicidad de clave (totalmente improbalble) volveríamos al error y le sumaríamos otra unidad. Así hasta que no se diera error. Ahora, como el usuario no tiene ni idea del número de factura que acaba de introducir (porque no lo ha decidido él, sino la aplicación y en segundo plano) yo, personalmente, le devuelvo un MsgBox con " se ha dado de alta el número de factura XXXXXX " (por avisarle de alguna manera)
Es decir, si sólo abres el recordset en los momentos estrictamente necesarios para las actualizaciones, juegas con la ley de probabilidad a tu favor y, en caso de que se dieran errores, solucionarlos, como ves, es sencillo (independientemente del tipo de conexión que utilices)
Ahora, te comento, esta manera de proceder funciona cuando estás desarrollando una aplicación "contra access" (o contra cualquier otro proveedor de datos) pero no es viable (o es poco operativa) si la aplicación es "en access" (es decir, una aplicación VB, por ejemplo, contra access)
Si te das cuenta no te he comentado nada de RDO ni te he pasado una línea de código, lo siento, pero es que como te comento, no he utilizado RDO en la vida.
