Access - Error 2950 cuando se cancela BeforeUpdate

Hola,
En el evento BeforeUpdate compruebo si están rellenos todos los campos de un formulario para dar opción al usuario a que complete los que están en blanco antes de abandonarlo.
Cuando este evento se dispara al intentar cerrar el formulario (que ha sido modificado) y provoco su cancelación (poniendo Cancel = True), obtengo una sucesión de errores que causan que Access se cuelgue completamente. Los errores son estos:

1) "Es posible que <la base de datos> haya encontrado un error mientras intentaba guardar un registro. Si cierra el objeto ahora se perderán los cambios que realizó. ¿Desea cerrar el objeto de Base de datos de todas formas?" Sí/No.

Si respondo que sí, entonces la catástrofe está asegurada, porque:
a) O bien me ignora y no cierra el formulario
b) O aparece un cuadro de diálogo diciendo que "la macro (no tengo ninguna macro) cmdClose provocó el error 2950. ¿Detener todas las macros?" Si digo que sí entonces Access se cuelga y para cerrarlo tengo que recurrir al Administrador de Tareas de Windows.

¿alguna idea, por favor? Ya no sé qué hacer!!!

Hola,

Efectivamente ese mensaje y algún otro similar se produce cuando tienes programado el evento BeforeUpdate del formulario y el usuario lo que hace es cerrar el formulario. Lo que creo que no es normal es que se bloquee Access.

Yo en esos casos suelo tener en la rutina de manejo de errores el chequear el error concreto (que hace referencia a que no se puede cerrar el form) para evitar mensajes etc. También puedes incluir en el evento FormError lo que necesites hacer (por ejemplo dar tus propios mensajes) y finalmente hacer "Response = acdataerrcontinue" para evitar los mensajes de Access.

En los casos más complicados, puedes quitarle al form el cuadro de Control (maximizar, minimizar, cerrar) poniendo a NO la propiedad "ControlBox" o desactivar el cerrado poniendo a NO la propiedad "CloseButton", le pones además un ComandButton que es el que tiene que pulsar el usuario para actualizar la tabla y en el evento click del mismo haces todas las verificaciones y actualizas o no y das los mensajes que necesites bajo tu control.

Saludos

Muchísimas gracias, Antonio.
Tengo puesto una gestión de errores que intenta hacer lo que dices en el evento Form_Unload pero no he debido acertar, porque no consigo evitar el error.
Si tienes a mano algún ejemplo con lo que tú haces, ¿te importaría enviármelo, por favor?

No puedo deshabilitar el cierre del formulario por diseño de la aplicación, pero me parece muy interesante lo que dices de obligar al usuario a guardar cambios mediante un botón especial para ello. Sin embargo, ¿cómo evito el comportamiento por defecto de Access que guarda automáticamente los cambios por el simple hecho de abandonar el registro modificado (por ejemplo pulsando el botón "Siguiente" en la barra de selectores de registro? Esta posibilidad creo que me evitaría muchísimos problemas, en mi caso sería fantástico conseguirla.

Muchas gracias de nuevo por tu ayuda

Hola,

Me temo que solo puedo dar ideas generales para evitar esos problemas, luego todo depende de los distintos eventos, de los controles y del propio form, los que te originan la barra de comandos de Access y la de desplazamientos del form. (Lo último que te imagines que puede hacer el usuario, es lo que acaba haciendo antes o después).

Es muy importante tener muy claro el orden en que se desecadenan los distintos eventos. (Si no recuerdo mal en la ayuda de la versión del 97 venía muy bien detallado). Eso es algo que dá mucha guerra a los que vienen de un entorno de programación procedural (por ej. Cobol) sin entornos gráficos ni objetos ni eventos

Hay muchos puntos donde puedes tocar:

En Form_Unload puedes comprobar si tienes nuevos valores aun sin guardar (con la propiedad Dirty del form) y cancelar el cerrado del formulario. Luego tendrás que tener cuidado cuando desde dentro intentes cerrar tu el form y te salta primero el evento Unload.

En Form_Error puedes verificar el número del error y eliminar los mensajes como te decía en el post anterior. También con la instrucción OnError dentro de cada evento.

Puedes sustituir la barra de menús de Access por la que tu prepares para todas tus funciones, sustituir las barras de comandos estandar por las que tengan lo que a ti te interesa y que preparas tu misma. Habilitar, deshabilitar y suprimir la barra de desplazamiento de registros al pie del form.

Solo a base de probar (en modo paso a paso cuando puedes hacerlo, por que ciertas operaciones no te deja hacerlas en modo de depuración) acabas cerrando todos los casos. Con el tiempo terminarás siguiendo casi siempre la línea general que mejores resultados te haya dado y que mejor domines.

Mi teoría es tener el mayor control posible de lo que se le permite hacer al usuario para que pase por donde tu has previsto y verificado que funciona, que lo programado en cada evento sea una verdadera caja negra, cuanto más corto mejor por que es menor el riesgo de provocar eventos en cascada.

Pero todo eso también aumenta el trabajo de desarrollo y depuración.

Espero no haber sido demasiado rollo. Saludos.

Muchas gracias, Antonio.
Mi lenguaje original de programación es C++, y estoy acostumbrada a trabajar con eventos, pero el orden en que se disparan en Access se me escapan. El hecho, por ejemplo, de que al abandonar un registro se guarde automáticamente no deja de sorprenderme. Me parece un comportamiento muy distinto al que Microsoft sigue por defecto en el resto de sus aplicaciones. No se me había ocurrido algo tan simple como sustituir la barra de Access por una mía. Eso es lo que haré: es la única manera de tener el control y hacer las comprobaciones que quiero.
Muchas gracias de nuevo por tu ayuda.
Un saludo.