¿Comprobar programáticamente la corrupción de la base de datos de Access?

Question

¿Hay alguna forma de verificar mediante programación la corrupción de objetos de base de datos en Access 2003?

Mi proyecto de desarrollo se ha vuelto lo suficientemente complejo como para que sea difícil revisar manualmente todos los objetos después de un día de programación para ver si algún objeto pequeño de control, formulario, informe, consulta u código se ha corrompido de alguna manera. Ya tengo los datos divididos en una base de datos SQL separada almacenada en otra máquina, y este proyecto no es más que una aplicación de front-end para trabajar con los datos.

Principalmente una reflexión académica, ya que simplemente no quiero llegar tan lejos, luego la corrupción me retrasó varias semanas porque algún objeto usado rara vez se corrompió cuando.

¿Alguna idea por ahí? Gracias de antemano por cualquier puntero!

EDITADO 03/12/2009 @ 11:51

Lamentablemente, solo puedo aceptar una respuesta, aunque obtuve algunas muy buenas, ¡gracias por todos los consejos!

Answer 1

Ni Compact / Repair ni Decompile / Recompile detecta todos los problemas de corrupción, aunque de todos modos debería hacerlo.

Utilizo una función para exportar todos los documentos de contenedor (y QueryDefs) usando SaveAsText en una carpeta con fecha / hora estampada, y lo uso regularmente durante todo el día. Si sospecho que hay algún daño, creo un nuevo mdb y uso LoadFromText para recrear los objetos.

Answer 2

Es posible que desee ver: ¿Es posible detectar mediante programación las tablas de base de datos de Access 2007 corruptas?

Me inclino a mantener una copia de las bases de datos importantes en cada compacta & amp; Reparar y comparar la nueva base de datos con la anterior. También puede comprobar si hay caracteres no estándar.

Answer 3

Las prácticas de compilación adecuadas evitarán la corrupción del proyecto VBA (que es de lo que estás hablando aquí).

Eso implica:

1. use OPTION EXPLICIT en todos los módulos.

2. apague COMPILE ON DEMAND en las opciones de VBE.

3. compila tu código regularmente, mientras trabajas.

4. periódicamente (por ejemplo, una vez al día después de un día completo de codificación) descompila y vuelve a compilar el código.

Si haces esto, nunca encontrarás corrupción en primer lugar, por lo que no tendrás que probarlo (lo cual es imposible en primer lugar).