Access, Excel, VBA y más

Access para Tablets – El acceso a los datos (2)

El acceso a los datos, los campos clave

Siguiendo con el artículo anterior «Desarrollando con Microsoft Access para Tablets«, vamos a desgranar el primer problema que nos vamos a encontrar cuando dejamos de usar Access de forma convencional e intentamos conectarnos a los datos que están en un servidor externo que es, ni más ni menos, que la gestión de los campos clave de nuestras tablas.

Pintemos varios escenarios hasta llegar al escenario real para entender el porqué de las cosas:

En primer lugar vamos a matizar que no trabajaremos con un solo fichero de Access donde estén tanto los datos como los formularios, consultas y demás objetos. Esta opción queda reservada para accesos a la base de datos mono usuario. Nuestra metodología consiste en tener por un lado el Front-End que es el fichero de Access con la lógica, o sea, los formularios, las consultas, los informes, el código de acceso a los datos, etc., y por otro la base de datos con las tablas y registros de nuestra aplicación. Esta base de datos puede estar en un fichero Access, como hemos visto en otras ocasiones, o, si prescindimos de Access para ello, en un servidor externo, bien sea SQL Server, MySQL, Oracle, etc.

Para ilustrar nuestro ejemplo imaginemos que trabajamos con la tabla de «AveriasElectricas» sobre la que estamos desarrollando esta serie de artículos.

Escenario 1 – Red local de varios equipos con un servidor

Este sería el entorno que tendría nuestra empresa de reparaciones eléctricas dentro de la oficina. Imaginemos que hay unos cuatro PCs conectados en red, donde un quinto PC haría de servidor alojando la base de datos, en nuestro caso otro fichero Access con todas las tablas, y los otros cuatro clientes con su fichero Access (Front-End) vinculado directamente a fichero Access del servidor. Haremos hincapié en que aquí tenemos acceso permanente y estable al servidor.

Cuando Access usa tablas vinculadas y creamos un nuevo registro, éste, se crea directamente en el fichero que contiene los datos. Nuestra tabla de «AveriasElectricas», que está en el servidor, tiene un campo ID autonumérico que asigna un número correlativo a cada registro nuevo que creemos.

Como los cuatro PCs están vinculados directamente al servidor cualquiera de estos PCs pueden dar de alta una avería y la tabla correspondiente, LA MISMA PARA LOS CUATRO PCs, creará este número clave que, recordemos, NO SE PUEDE REPETIR.

Escenario 2 – Red estable con acceso a servidor fuera de la red

Nos metemos en terreno farragoso, ahora tenemos un escenario parecido al anterior, sólo que la base de datos está en un servidor externo, al que hay que acceder mediante Internet pero, consideramos que la conexión a internet es tan fiable que hemos optado por seguir usando tablas vinculadas. Aunque ya adelanto que, aunque esta solución funciona, en la práctica, ya no es tan fiable ni rápido trabajar así con tablas vinculadas como en el escenario 1.

En esto blog ya hablamos sobre como vincular Access a una base de datos externa SQL Azure de Microsoft. Si damos por hecho de que hemos vinculado nuestro fichero Access al servidor nos encontramos con que los registros que demos de alta en la tabla «AveriasElectricas» las estamos haciendo directamente sobre el servidor por lo que, nuevamente, este asignará un número correlativo a cada registro que creemos. Así que podemos seguir usando nuestro campo autonumérico.

Escenario 3 – Acceso inestable o inexistente al servidor

Y llegamos a nuestra situación actual, hemos sustituido los PCs de la oficina con una conexión muy estable al servidor por unas Tablets y en la calle, en una situación donde no siempre tenemos acceso al servidor.

 

En esta situación descartamos VINCULARNOS directamente al servidor, tal y como ocurre en los escenarios 1 y 2. ¿Por qué? muy sencillo, porque si trabajamos con tablas vinculadas cuando no hay conexión seríamos incapaces de dar de alta nuevos registros al no tener acceso a la tabla «AveriasElectricas» de nuestro servidor.

Tal y como comentábamos en el artículo anterior la mejor opción en este caso era tener tablas locales en Access donde guardar los datos y, cuando recuperemos el acceso a Internet enviamos los registros al servidor. Pues vamos a ello…..¡UPS, pero los registros que demos de alta en las Tablets también tienen que tener un campo clave y único! claaaaaaro….veamos que pasa:

Campos clave en cada tablet autonuméricos. Numérico en la misma tabla del servidor.

En nuestra tabla «AveriasElectricas» del programa que tenemos en las Tablets hemos configurado su campo ID como autonumérico. Recordemos que estas Tablets ahora van por libre hasta que decidamos enviar todos los registros, de cada una de ellas, al servidor y juntarlos todos allí.

Como son independientes va a pasar lo siguiente cuando cada uno de los usuarios, en sus Tablets, empiecen a dar de alta registros a la espera de subirlos al servidor:

Tablet Nº Nº Reg. Avería
1 1 Avería en cuadro de luces
1 2 Sin luz en edificio Mar de plata
1 3 Torre eléctrica en parque sur con chispazos.
2 1 Cliente Luis le salta la Luz intermitentemente
2 2 Garaje en C/Liébana se ha ido la Luz
3 1 Centro Comercial, ampliar luminarias pasillos
3 2 Tienda Golosinas Maype, Stand da la corriente
4 1 Cobertizo de Andrés sin luz
4 2 Garaje de Cosme cambiar tubos por Led
4 3 Disco Henrry’s instalar luces de neón

En esta situación, equipos distintos están generando los mismo números ID que luego deberemos de introducir en la misma tabla del servidor pero ya sabemos todos que cuando subamos al servidor el registro 1 de la Tablet 1, no será un problema, sin embargo, cuando subamos al servidor el registro 1 de la Tablet 2, éste nos devolverá un error indicando que ese número de ID ya existe en el servidor así que tendríamos un problema, y no pequeño.

Al subir al servidor ignoramos el autonumérico de la Tablet para dejar que lo cree el servidor, el que le corresponda.

Esta sería otra posible opción, por si se te está ocurriendo. Lo que podemos hacer es ignorar el campo clave que se está creando en la Tablet y cuando subamos al servidor el registro, independientemente de la Tablet que lo haga, subimos todos los campos EXCEPTO el ID que dejaremos que lo cree el propio servidor según corresponda. ¿Fácil verdad? Pues no corras tanto querido lector que no siempre es tan fácil el asunto.

Con una sola tabla podría valer pero la experiencia me dice que no será siempre una sola tabla, ¿por qué? porque seguramente nuestra tabla de «AveriasElectricas» tendrá otra tabla relacionada que podrá llamarse «AveriasElectricasComponentes» donde el técnico irá dando de alta todas las piezas que ha usado en la reparación.

¡Pues ala!, dos tablas relacionadas ¿ahora que hacemos? Esto se empieza a poner difícil porque en la Tablet, ambas tablas están relacionadas y Access, tan listo, guapo e inteligente como siempre, a cada registro que demos de alta en la tabla «AveriasElectricasComponentes» de la avería número 1, por ejemplo, automáticamente le pondrá el mismo número en su campo relacionado para que podamos saber que componentes hemos asignado a la avería número 1.

Tablet Nº Nº Reg. Avería Nº Reg. Relac. Componentes utilizados
1 1 Avería en cuadro de luces 1 2m cable rígido
1 1 Avería en cuadro de luces 1 Fusible de 5A
1 1 Avería en cuadro de luces 1 2 Module IP40

 

Pues igual que antes, ¿no?, a ver, que no debe ser tan complicado… repasemos los pasos:

  1. Subimos el registro número 1 de la Tablet 1.
  2. Buscamos en el servidor cual es el último número (ID) asignado al registro.
  3. Subimos los tres registros de componentes asignando, a su campo ID, el número que hemos recuperado del servidor.

Pues no era tan difícil, ¿no?

Querido lector, que pasa si?:

  1. Subimos el registro número 1 de la Tablet 1.
  2. EL DE LA TABLET 4 CURIOSAMENTE ACABA DE SUBIR UN REGISTRO.
  3. Buscamos en el servidor cual es el último número (ID) asignado al registro.
  4. Subimos los tres registros de componentes asignando, a su campo ID, el número que hemos recuperado del servidor.

Pues que si nos descuidamos, cuando subamos todos los registros, estaremos asignando los componentes de la avería 1, de la Tablet 1, a la avería subida por la Tablet 4.

Ya conocemos al amigo Murfy, así que si es probable, aunque sea muy remota la posibilidad, de que ocurra que dos usuarios a la vez estén subiendo registros al servidor seguro que nos pasa a nosotros y nos fastidia el invento.

Y todo esto nos pasa porque si hemos programado toda la vida con Access siempre hemos usado los autonuméricos y el propio Access se ha encargado de hacer casi todo el trabajo por nosotros que hemos estado acomodados, sin preocupaciones. Ahora el sistema cambia. Access ya no puede solucionárnoslo todo.

¿A que es divertido? pues imagínate cuando te das en la cabeza con él la primera vez hasta que encuentras un sistema medianamente efic………¡EUREEEEKA! CREO QUE LO TENGO!…..se me acaba de ocurrir otra idea genial!! 

Pues como este artículo se ha hecho un poco extenso y aún vienen muchos más te dejo que me la cuentes en el próximo artículo e intentamos juntos seguir buscando esta solución milagrosa.

PD: Si has llegado hasta aquí aún te estarás preguntando porque te estoy contando tanto rollo en vez de ponerte la solución más eficaz directamente, ¿verdad?. Pues porque si hago eso te lo estaría poniendo demasiado fácil y no te haría pensar, y con Access, se aprende pensando y equivocándose, sobre todo equivocándonos aprendemos a caminar hacia adelante. Así que esta será la metódica que usaré a lo largo de toda esta serie de artículos, que son muchos, seguro que me lo agradecerás.

Si pinchas el siguiente enlace podrás ver el resto de artículos relacionados con el tema «Desarrollando con Microsoft Access para Tablets«

Salir de la versión móvil