Velocidad y compactación.
Te voy a plantear dos cuestiones: Tengo una aplicación multiusuario trabajando con Access Runtime. La base de datos es un archivo MDB Access 2000 que está en el servidor. Cada cliente tiene la aplicación en un archivo MDE Access 2002, que consulta las tablas del archivo del servidor mediante el sistema de tablas vinculadas. El método que utilizamos es crear una unidad z: de red que apunta a la carpeta del servidor con el archivo MDB que contiene las tablas vinculadas. Hay algunos equipos que tienen problemas de velocidad a la hora de consultar tablas más o menos grandes y me gustaría saber si hay alguna forma acelerar los accesos a las tablas.
La segunda pregunta es si puedo compactar el archivo MDB del servidor sin abrirlo con Access o con el Runtime. Conozco la opción de "compactar al cerrar", pero ello implica necesariamente el abrirlo de forma directa. Lo que necesitamos es compactar el fichero MDB desde el MDE.
La segunda pregunta es si puedo compactar el archivo MDB del servidor sin abrirlo con Access o con el Runtime. Conozco la opción de "compactar al cerrar", pero ello implica necesariamente el abrirlo de forma directa. Lo que necesitamos es compactar el fichero MDB desde el MDE.
1 respuesta
Respuesta de rauljj
1
Velocidad:
La velocidad en Access cuando trabaja en red es un problema, cuando tu ejecutas una consulta desde un cliente, access se trae toda la tabla al cliente a través de la red, por eso se dice que Access es servidor de ficheros y no propiamente cliente-servidor. Se pueden acelerar las consultas de dos formas, una es con índices en función de la consulta y otra es vigilando cómo se hacen las consultas inner join. Siempre se ha de hacer el inner join en el sentido de la relación uno a muchos, esto se refleja en el diseñador de consultas en el sentido que arrastramos un campo de una tabla a otra. Si por ejemplo tenemos una tabla Facturas relacionada uno a muchos con una tabla conceptos facturas el inner join iría de facturas a conceptos facturas, es increíble la velocidad que se pierde cuando se hace al revés.
En cuanto a compactar la base de datos hay unos métodos compactdatabase y repairdatabase que compactan y reparan la base de datos, es imprescindible que no haya nadie trabajando con la base de datos cuando se haga esto (salvo el mde que esté compactando y reparando). Yo tengo un archivo.ini en el servidor, el primero que entra comprueba la fecha de la última compactación y si ha pasado más de por tiempo compacto y reparo la base de datos automáticamente, de paso hago una copia de seguridad a otro disco o dispositivo que sé que siempre está disponible.
La velocidad en Access cuando trabaja en red es un problema, cuando tu ejecutas una consulta desde un cliente, access se trae toda la tabla al cliente a través de la red, por eso se dice que Access es servidor de ficheros y no propiamente cliente-servidor. Se pueden acelerar las consultas de dos formas, una es con índices en función de la consulta y otra es vigilando cómo se hacen las consultas inner join. Siempre se ha de hacer el inner join en el sentido de la relación uno a muchos, esto se refleja en el diseñador de consultas en el sentido que arrastramos un campo de una tabla a otra. Si por ejemplo tenemos una tabla Facturas relacionada uno a muchos con una tabla conceptos facturas el inner join iría de facturas a conceptos facturas, es increíble la velocidad que se pierde cuando se hace al revés.
En cuanto a compactar la base de datos hay unos métodos compactdatabase y repairdatabase que compactan y reparan la base de datos, es imprescindible que no haya nadie trabajando con la base de datos cuando se haga esto (salvo el mde que esté compactando y reparando). Yo tengo un archivo.ini en el servidor, el primero que entra comprueba la fecha de la última compactación y si ha pasado más de por tiempo compacto y reparo la base de datos automáticamente, de paso hago una copia de seguridad a otro disco o dispositivo que sé que siempre está disponible.
