database - sirve - Creciente problema de tamaño de archivo de MS Access

microsoft.ace.oledb.12.0 download x64

Question

Tengo una gran aplicación MS Access con muchos cálculos 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 mejor manera?

Gracias

Answer 1

Debería poder ejecutar la función compacta desde su código VBA.

Tenía el fragmento de abajo 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 poner eso en su código para evitarlo.

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

Answer 2

No soy un MVP, pero Google encontró estos. Tal vez te ayuden:

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

Answer 3

¿De qué tamaño 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.

EDITAR: 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 Access que he visto tienen muchas oportunidades para refactorizar; 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 acerca de 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

De acuerdo con 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 5

Desafortunadamente, MS Access tiene problemas cuando se vuelve demasiado grande, creo que el tamaño máximo es de 2 GB para un DB de acceso.

Puede considerar mudarse a Sql Express, VistaDB, etc.

Answer 6

Llevaría los datos a MS SQL (los datos permanentes y las tablas intermedias); 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 estables / confiables (no puedo decirte cuántas veces he tenido una base de datos corrupta de MS Access).
2. Su base de datos de Access no crecerá / cambiará mucho (debe alcanzar un equilibrio una vez que todo el código se haya ejecutado y compilado).

Ambos significan no tener que 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 o similar, puede excavar las siguientes ideas:

• Abra otra base de datos de acceso ''externo'' (archivo mdb) para todas las tablas temporales, de modo que pueda poner todos los datos temporales en el archivo externo, tirando el archivo mdb cuando cierre la aplicación. A continuación, manipulará en su código el objeto ''currentDb'' y otra base de datos que compilará al inicio y se conectará a través de la conexión a chorro, OLEDB o ODBC
• Separe sus tablas permanentes de su código y, cuando sea necesario, traiga los datos a la interfaz de su 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 archivos Jet es interminablemente problemático para mí.

Actualmente estoy viendo una parte de mi propio código VBA desde la base de datos A de acceso, ya que realiza una serie de actualizaciones de campo de registro único utilizando ADO a una tabla en la base de datos de acceso B (a través de una referencia de consulta actualizable en la base de datos A). 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, compré / 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 los anteriores (ninguna crítica en particular para cualquier 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 encomiendo a los escritores anteriores por encontrar soluciones a los problemas de los usuarios. Sin embargo, no puedo permitir que soporte cuando el diseño / implementación deficiente del software se interpone en el camino de los usuarios que usan un producto, ya que los usuarios esperan que funcione.