Creciente problema de tamaño de archivo de acceso de MS

Question

Tengo una aplicación grande de MS Access con muchos cómputos en código VBA. Cuando lo ejecuto, eventualmente se cuelga debido al excesivo tamaño del archivo. Hay muchas tablas intermedias y consultas creadas y posteriormente eliminadas, pero Access no recupera el espacio. He cerrado diligentemente todos los conjuntos de registros intermedios y he desactivado todos los objetos temporales, pero nada ayuda. La única forma en que puedo hacer que mi código se ejecute es ejecutar una parte, detener y reparar/comprimir el archivo y luego reiniciar el código.

¿No hay una forma mejor?

Gracias

Answer 1

no soy un MVP, pero Google encuentre este tipo. Tal vez van a ayudarle a:

http://www.mvps.org/access/general/gen0041.htm http://forums.devarticles.com/microsoft-access-development-49/compact-database-via-vba-24958.html

Answer 2

Desafortunadamente, MS Access tiene problemas cuando llegue demasiado grande - Creo que el tamaño máximo es de 2 GB para una base de datos de acceso.

Es posible considerar mudarse a SQL Express, VistaDB, etc.

Answer 3

Qué tamaños estás tratando? ¿Cuál es el código de error cuando se bloquea? Me sorprendería si es simplemente porque el archivo se vuelve "demasiado grande", pero imagino que hay un límite. Según su descripción de todas las cosas de la temperatura, puede que haya mejoras de diseño que podrían ayudar.

EDIT: supongo que se dará cuenta de que no es trivial reemplazar la base de datos con otra cosa, incluso si intenta mantener todo lo demás en el mdb además de las tablas. Los querydefs de acceso son únicos, Access SQL no es estándar y básicamente comenzarías de nuevo.

La mayoría de las aplicaciones de acceso que he visto tienen muchas oportunidades de refactorización; y por lo general no es tan difícil si a) comprende la lógica y las reglas comerciales, yb) tiene una sólida comprensión de la programación de acceso. Pero eso sería más o menos cierto para cualquier alternativa. Si yo fuera tú y estás un poco corto en cualquier área, tal vez puedas obtener ayuda. Pero trataría de rescatar la aplicación de Access primero.

También hay una sugerencia de otro afiche sobre mover las tablas a uno o más MDB adjuntos. Esa es una técnica sólida y bien probada en general. Pero antes tendría una idea de cuál es la verdadera causa del problema.

Answer 4

Debe poder ejecutar la función compacta desde dentro de su código VBA.

Tenía el siguiente fragmento marcado desde hace mucho tiempo cuando estaba haciendo el trabajo de acceso.

Public Sub CompactDB() 
    CommandBars("Menu Bar").Controls("Tools").Controls("Database utilities").Controls("Compact and repair database...").accDoDefaultAction 
End Sub 

Puede ponerlo en su código para evitarlo.

NOTA: también puede considerar crecer a un sistema de db más grande si tiene este tipo de problemas de escala.

Answer 5

Según http://office.microsoft.com/en-us/access/HP051868081033.aspx, Access 2003 y 2007 tienen un límite de 2 GB. Sin embargo, es fácil mover algunas o todas las tablas en un archivo .mdb separado y luego vincularlas a esas tablas. De todos modos, es una buena práctica tener dos archivos, uno para sus datos y otro para todas las macros, consultas, etc. Incluso podría tener varios archivos si su archivo de tabla se acerca al límite de 2 GB.

Answer 6

Me empujo a los datos a través de MS SQL (los datos permanentes y los cuadros intermedios); y puede dejar la porción de código en MS Access por el momento.

Esto resuelve dos grandes problemas:

1. Los datos serán inherentemente más estable/confiable (No puedo decirle cuántas veces he tenido una base de datos de MS Access corruptos).
2. su base de datos Access no crecerá/cambiar mucho (que debe llegar a un equilibrio una vez que todo el código se ha ejecutado y compilado).

Ambos significan no tener que comprimir/reparar la base de datos; puede obtener una versión gratuita (Express Edition) de MS SQL y no es tan difícil de hacer.

Answer 7

Si no desea cambiar a SQL Express y similares, se puede excavar las siguientes ideas:

• abierto otra base de datos de acceso 'externo' (mdb) para todas las tablas temporales, por lo que podría poner todos los datos temporales en el archivo externo, descartando el archivo mdb cuando cierras tu aplicación. A continuación, manipulará en su código el objeto 'currentDb' y otra base de datos que compila al inicio y se conecta a través de la conexión Jet, OLEDB u ODBC
• Separe las tablas permanentes de su código y, cuando sea necesario, transfiera los datos a su interfaz de cliente local para construir sus tablas temporales. Esto se puede hacer, por ejemplo, vinculando la base de datos externa al archivo local/cliente usando "DoCmd.transferDatabase acLink". Esto también puede hacerse conectándose a los datos permanentes a través de la conexión OLEDB, abriendo los conjuntos de registros necesarios y guardándolos localmente como archivos XML. Hay muchas otras soluciones que se pueden implementar aquí.

Answer 8

El estado de cosas con respecto a los tamaños de archivo Jet es interminablemente problemático para mí.

Actualmente estoy viendo una pieza de mi propio código VBA de base de datos Access A como lo hace una serie de un solo registro de campo actualizaciones utilizando ADO a una tabla en la base de datos de acceso B (mediante una referencia actualizable-consulta en la base de datos UN). El campo individual es un CHAR (8). Con cada 4 actualizaciones que pasan, la base de datos B crece alrededor de 8 Kbytes. No hay una buena excusa para eso. La adición al tamaño del archivo ralentiza el rendimiento en esto severamente; con cada crecimiento de archivos, las actualizaciones se ralentizan desde aproximadamente uno por segundo (en una tabla de aproximadamente 30-40K registros usando búsquedas SQL de registros únicos y sin índices en cualquier lugar) hasta uno por cada 5-10 segundos. Ahora, lo admito, compaqué/reparaba la base de datos B antes de ejecutar este código de actualización; quizás si no hubiera hecho eso, el rendimiento no hubiera sido tan malo. Si el campo objetivo para la actualización hubiera sido, por ejemplo, escribir Memo, entonces habría esperado esto. Pero llevar a cabo una actualización en un campo CHAR() y obtener este resultado simplemente no es razonable.

La mayoría de las anteriores (ninguna crítica en particular para una solución) son soluciones válidas para aplicaciones que usan un arreglo de aplicaciones de negocios relativamente permanente (hable con las mismas bases de datos de destino todo el tiempo). El mio no es asi . . No puedo modificar la base de datos de destino (base de datos B), ya que es generada y consumida por la herramienta de un proveedor que utilizamos para exportar e importar datos desde su aplicación.

entiendo y felicitar a los autores anteriores para encontrar soluciones a los problemas de los usuarios. Sin embargo, no puedo dejarlo en blanco cuando diseño 0 implementación de software pobre se interpone en el camino de los usuarios que usan un producto como los usuarios esperan que funcione.