VBA, Access. Optimizar rendimiento con BackEnd en red + ¿CurrentDb como variable general?
Tengo una aplicación compleja con FrontEnd en PC Local y BackEnd en Red para que sea multiusuario.
El tema es que cuando corre en Red va más lento que si tengo el BackEnd en PC Local... Y todavía más lento (lentísimo) si la conexión a la red se hace con VPN.
Por lo tanto me encuentro investigando posibles soluciones para mejorar el rendimiento. Cualquier ayuda es de agradecer.
De lo que sí me he dado cuenta es que cuando inicio los procedimientos de calculo por VBA (normalmente con DAO), siendo muchos procedimientos iterativos, y observando el "Rendimiento" del "Administrador de Tareas" veo que los accesos a Ethernet van con muchos picos. Viendo esto me he dado cuenta que cuando los ejecuto el BackEnd crea y borra constatemente el archivo "*.laccdb".
He pensado que quizá una posible mejora es declarar una variable general (dim db_ALL as DAO.Database) por cada vez que se abra un formulario (Set db_ALL = CurrentDb en Form_Open) y que se declare nothing cada vez que se cierra... De esta manera creo que podría evitar la carga continuada de la base de datos... Pero tengo varias dudas;
- ¿Esto me mejoraría realmente el rendimiento? ¿Merece la pena invertir tiempo en revisar todo el codigo VBA para convertir las llamadas de CurrentDb a la variable general db_ALL?
- Si declaro el db_ALL al inicio de cada formulario, ¿corro el riesgo de no tener actualizados los datos y las consultas de la base de datos cada vez que hago un OpenRecordset? Es decir, un usuario cambia un dato, que afecta a una consulta, y después le da a un botón que ejecuta varias operaciones de OpenRecorset.
- Al declarar el db_ALL al inicio de cada formulario, ¿podría estar bloqueando otros usuarios? ¿O bloqueando actualizaciones en ese formulario por otros usuarios? ¿O bloqueando otras tablas/consultas?
- Si mejora el rendimiento y no hay problemas de actualizaciones/bloqueos, ¿merece la pena declarar db_ALL en cada formulario o sería mejor declararlo nada más abrir la Base de Datos?
1 respuesta
¿Qué llama aplicación compleja?. ¿No indica cuántos clientes conecta con el BackEnd?. He respondido en varias oportunidades sobre el uso de Access en un sistema cliente-servidor. Hay varias situaciones que dependen el tiempo de acceso a datos. Primero NO debe utilizar DAO para aplicaciones cliente-servidor, en su defecto use ADO. DAO es para aplicaciones Jet locales. Un factor importante es el servidor de datos, seguro que si utiliza un disco de estado sólido mejorará el rendimiento, igualmente, la memoria RAM debe ser como mínimo de 8 GB.
Por otra parte, de nada le sirve una variable pública para establecer la conexión si al cerrar un formulario utiliza Nothing, esto hace que se pierda la definición inicial.
Una solución y para mi concepto la mejor, es migrar a PostgreSQL la base de datos, este es un servidor de código abierto, en donde por defecto puede conectar 100 usuarios (no posible en Access) sin afectar el rendimiento. Si utiliza consultas de paso a través obtendrá la respuesta 10 veces más rápido que utilizando consultas de Access, porque estas se hacen directamente en el servidor.
Tenga cuidado Access es muy celoso cuando se conecta al servidor con diferentes versiones de Access y Windows, llegará el momento en que no podrá tener acceso a los datos, tuve ese problema hace unos años.
Otra ventaja de trabajar como servidor de datos con PostgreSQL es que ya ha recorrido un buen camino para migrar a Linux y aplicaciones web.
Si necesita asesoría para migrar los datos a PostgreSQL puede contactarme en [email protected].
Excelente ayuda Eduardo... me dejas muchas tareas con las que ponerme al día, jeje.
Me parece muy interesante PostgreSQL, pero de momento no quiero migrar ya que cuando lo haga plantearé un verdadera migración a MSSQL y Visual Studio. Además no soy informático y de momento no tengo acceso a los servidores; por lo que lo más práctico era independizarme con una base de datos en el que poder tener ficheros para backend y frontend, para manejarlos a mi antojo.
Realmente interesante me parece la migración de DAO a ADO; creo que empezaré por aquí y me iré encontrando con problemas a solucionar. Tiene pinta de que se mejorará el rendimiento; pero me da que llevará un tiempo actualizarlo.
Respecto a declarar la variable general CurrentDB al abrir la base de datos (en lugar de abrir el formulario), ¿lo ves práctico? En el primer post planteo una serie de preguntas desde el desconocimiento, ¿podrías echarme un cable para entender cómo funcionan las tripas de Access en este sentido?
De nuevo muchas gracias.
Si sabe visual studio no dude en hacerlo. Respecto a mysql este lo compro oracle y no va ser gratis y es mucho mas potente postgresql y sigue siendo gratis.
Entiendo que hacer el cambio de Access a Postgresql se ve dificil pero no es asi. Lo bueno es que no pierde sus consultas formularios y reportes. Si quiere envieme su base de datos y miro que tan viable es la conversion. Pero vuelvo y le recomiendo migre sus datos por seguridad y agilidad.
No le respondo sobre CurrentDB porque trabajo es con Access y PostgreSQL es otro mundo. Pero no creo que mejore mucho.
