Creacion de aplicaciones multiusuario

Creación de Aplicaciones multiusuario – 1
Ejecución de Access en red
La primera decisión a que tenemos que enfrentarnos cuando creamos una aplicación
multiusuario de Access es dónde poner los archivos de la Base de Datos. Podemos elegir
instalar de dos formas:
1. Instalar la Base de Datos completa de Access en el servidor, lo que permite a todos
los usuarios ejecutar Access desde su estación de trabajo hacia el servidor.
2. Instalar la aplicación de Access con tablas vinculadas en cada estación de trabajo y
compartir solamente los datos de la Base de Datos entre los usuarios de la red.
Instalación de la aplicación en el servidor
Muchos programadores noveles en las aplicaciones de Access en red eligen instalar Access
Access en el servidor, como se indica en la primera opción.
La ejecución de Access en el servidor tiene las ventajas siguientes:

Se emplea poco espacio o ninguno en las estaciones de trabajo.

El software se actualiza fácilmente, porque solamente es preciso actualizar un
conjunto de archivos.
Aunque ésta es la solución más fácil, no es la mejor. Durante la ejecución de Access
se producen numerosos accesos al servidor de red. Cuando todos los archivos están situados
en el servidor de red, éste acceso constante degrada el rendimiento de la red y ralentiza la
aplicación de forma significativa. Sin contar con otros problemas habituales de bloqueo de la
aplicación por un uso inadecuado del bloqueo de registros.
Instalación de Access en cada estación de trabajo
Para solucionar éste problema de rendimiento en la ejecución de Access en red, se
puede ejecutar localmente en cada estación de trabajo, accediendo solamente a los datos
compartidos que se almacenan en una Base de Datos en el servidor que contiene solamente
las tablas de la Aplicación. Dado que la conexión de red se emplea únicamente para la
transmisión de datos y no para cargar y ejecutar Access, el funcionamiento general de la
Aplicación es mucho más rápido, más seguro, y sin duda alguna, la forma correcta de instalar
la Aplicación en red.
La única desventaja real de ésta forma de instalación es el incremento en el tiempo
de mantenimiento. Aún así, hay formas de realizarlo que resultan extremadamente sencillas,
como más adelante se indicará.
Para realizar la instalación de Access de ésta forma
se deben llevar a cabo los
siguientes procesos:
1. Dividir la Base de Datos mediante el asistente de Access, de forma que en una Base
de Datos – Back End - quedarán las tablas, y en la otra – Front End - el resto, con las
consultas, formularios, informes etc.
2. Instalar el Backend , la parte de las tablas en el servidor de la red
3. Instalar el Frontend en una de las estaciones de trabajo. Con el asistente para
administrar las tablas vinculadas apuntar cuando salga el buscador hacia el Frontend
instalado en el servidor.
4. Hacer una copia de éste Frontend, que ya tiene las tablas bien vinculadas, e instalar
en cada estación de trabajo. Mi hábito personal es renombrar luego cada Frontend
para evitar cualquier conflicto de nombres, por ejemplo, MiBase1, MiBase2, etc.
Una vez realizados todos los pasos, tenemos ya lista la aplicación para trabajar desde
cada puesto de trabajo, con la ventaja de que por la red solamente circularán los datos
almacenados en la aplicación.
Dividir la Base de Datos
Para poder instalar Access a nivel de estaciones de trabajo tenemos que empezar por
dividir las tablas donde se almacenan los datos, de todos los demás objetos de la Base de
Datos, de forma que obtengamos dos Bases de Datos para la Aplicación.
DISEÑO
TABLAS
Consultas
Formularios
Vinculos con
Tablas
Macros
Tablas
Informes
Módulos
División de los objetos en dos Bases de Datos
Al tener en cada estación de trabajo la parte de formularios, informes, etc, el
rendimiento es muy superior a la primera opción que hemos señalado. Imaginemos abrir un
formulario complejo, cuyo diseño tuviéramos que pasarlo a través de la red para cada
estación de trabajo. En poco tiempo, la capacidad de tráfico de la red se podría ver
colapsada. De ésta segunda manera, los formularios están en cada estación de trabajo, por lo
que su apertura es prácticamente instantánea.
Una vez dividida la Base de Datos, el propio asistente genera la vinculación de las
tablas. Pero como normalmente la división la realizamos en el puesto de trabajo del
programador de la aplicación, cuando pongamos la base de datos de las tablas en el servidor,
el Frontend tendrá un vínculo a las tablas que no es el actual. Para ello, en la Barra de menús
de Access, en Herramientas > Administrador de tablas vinculadas tenemos un asistente que
nos permite buscar la ubicación actual del backend de las tablas y actualizar los vínculos.
En este punto hay que señalar que la división de una base de datos no es solo
conveniente por una cuestión de tráfico de red, sino necesario cuando estamos desarrollando
la aplicación para poder actualizar los cambios en el diseño de consultas, formularios,
informes, código VBA, etc. Si no hemos dividido la Base de Datos y el cliente nos solicita
algunos cambios, ¿qué vamos a hacer si ya está introduciendo datos?
Si hemos dividido
previamente la base de datos, la parte de las tablas seguirá siendo la misma, y podremos
cambiar cualquier parte de diseño, simplemente cambiando el frontend de cada estación de
trabajo por el Frontend con las nuevas modificaciones. Eso sí, en todo momento vigilando que
la vinculación de las tablas sea la correcta.
Actualización de vínculos de las tablas
Con independencia de qué método utilicemos para vincular tablas, ya sea mediante el
asistente de Access o mediante código VBA, es preciso capacitar a nuestra aplicación para
reparar los vínculos rotas, si no queremos acudir a repararlos personalmente cada vez que un
usuario o el administrador de la red mueva la carpeta que contiene la base de datos o cambie
el nombre.
La forma manual de vincular tablas mediante el asistente de Access ya la hemos
explicado. Existe una forma de hacerlo mediante código VBA que nos va a permitir que el
usuario disponga de un botón que le permita de forma sencilla actualizar los vínculos.
- Detectar cuando se rompe un vínculo
Para evitar sorpresas al usuario poco experto en temas de programación es
conveniente proveer a la aplicación de un sistema que al iniciarse detecte si se ha roto algún
vínculo de las tablas. De ésta manera, podemos parar la ejecución de la aplicación e indicarle
al usuario que las tablas no están donde estaban y que hay que decirle al programa dónde se
encuentran.
Para comprobar la validez de un vínculo, simplemente hay que hacer referencia a una
propiedad TableDef de la tabla vinculada y tratar los errores que se produzcan. Supongamos
que se produce el error siguiente:
Error 3265 – El elemento no se encuentra en ésta colección
Este error indica sencillamente que el vínculo se ha perdido. Entonces, para hacer
ésta primera comprobación, crearemos una función en la ventana módulos que compruebe si
efectivamente hay error o no.
Esta función mira si se produce el error que detecta si el vínculo se ha roto o no. Si se
ha roto devuelve False y si no se ha roto devuelve True. Ahora podremos utilizar éste
resultado para, primero, avisar al usuario del problema, y después revincular las tablas.
Esto lo podemos hacer en un formulario de inicio de la aplicación, que lo abrimos de
forma predeterminada, y para ello creamos un procedimiento en el evento Al abrir del
formulario Inicio:
Una vez que hayamos determinado que se ha roto un vínculo de las tablas, hay que buscar el
nuevo emplazamiento de la base de datos del servidor, la que contiene las tablas. Para ello
implantaremos un nuevo módulo que se lo facilitaremos a nuestro cliente.
En el próximo capítulo veremos cómo realizar ésta operación que, sin duda, nos
evitará muchos problemas de mantenimiento una vez instalada la aplicación.