Desarrollando con Microsoft 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

datos

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.

Access en redEn 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.

Access en red

 

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

Estudió formación profesional en la rama de electrónica hasta que descubrió el apasionante mundo de los ordenadores personales. Desde entonces, la administración de bases de datos, hojas de cálculo y programación en Microsoft Visual Basic para aplicaciones le han acompañado hasta el día de hoy. En estos momentos, su principal interés está enfocado a portabilizar las bases de datos a dispositivos móviles Windows e IOS, en entornos cliente servidor, enfocado en desarrollos con Microsoft Access, FileMaker y Servidores en la nube como Microsoft SQL Azure.

11 Comments

  1. Responder Carlos

    Hola @docebit estoy leyendo tus artículos, que estan realmente interesantes y te aliento para que sigas escribiendo, ya que no es facil encontrar muchas personas con buenos conocimientos y didactica, que dediquen su tiempo a capacitar a los no tan conocedores de access.
    He usado access 97, 2000 y 2003 (muy poco 2007 no me gusto) y estos temas los he resuelto en otra epóca en access con las replicas, pero en este caso partícular tendria una tabla lokeo con un campo booleano que leo y si esta en false pongo en true y grabo los datos y al terminar pongo de nuevo en false. Sí cuando lo leo esta en true (alguien esta grabando) corro un temporizador de 1 segundo e intento otra vez hasta leerlo en false y entrar.
    Saludos y sigue así

  2. Responder Antonio Jesús Moreno

    Muchas gracias por tu interesantes artículos sobre Access en Tablets. No nos hagas esperar mucho, jajajaja, que estamos ansiosos de conocimiento.

    Te agradezco enormemente que compartas tus conocimientos con todos nosotros.

  3. Responder marjan

    Creo que lo de eliminar la Replicación en A2013 es una putada. Me Iba muy bien para sincronizar rápidamente las tablas desconectadas sin pensar demasiado. Ahora busco una solución, a ver como lo resuelves tu…

    Quizás una solución sería un procedimiento y crear Identificadores personalizados (calculados) (como hacía Eva Etxebeste en sus tiempos) para cada registro de las tablas principales, por ejemplo, con el prefijo del nombre de máquina o su ip o el nombre de usuario, pero también supondría que la aplicación fuera poco flexible…. En fin…

    Saludos,
    marjan

  4. Responder absalon malafay

    @docebit:
    Gracias y sigue así, he trabajado con access 97, 2000, 2003 y 2010, todo lo hacia empíricamente, errando muchas veces, pero la satisfacción esta cuando te sale después de muchos intentos y vuelves a empezar con otros requerimientos, gracias tus tutoriales me sirven de gran ayuda. Que Dios nos ilumine y sigamos contribuyendo con nuestros semejantes.

    Saludos

    Absalon

  5. Responder Evaristo

    Estoy ansioso con estos artículos tuyos, hace ya tiempo que estamos pensando en suministrar a nuestros operarios con tablets o móviles para que puedan reportar tiempos y material directamente desde casa del cliente. Como puedes comprender tus artículos son precisamente eso por lo que me ahorraría mucho tiempo tener tu experiencia en ese campo. El proceso de prueba y error es lento y muy tedioso y cuando se trata de facturar un error puede costarte muy caro, tanto en dinero como en prestigio.
    Según planteas yo lo que a priori haría seria en las tablas móviles 2 indices únicos. Uno usado por cada dispositivo móvil para identificar únicamente los registros A1, A2, A3 (dispositivo A) B1, B2, B3 (Dispositivo B. Etc) En el momento de la sincronización usar el campo único principal de la base de datos principal para rellenar el segundo campo único de ese modo no creariamos duplicados y mantendriamos la coherencia. Siempre sabiendo de donde han llegado los datos facilitados.

    Estoy seguro que hay varias soluciones a un mismo problema cada uno aporta su granito de arena.

    Estoy impaciente por saber como lo has solucionado tu. Un saludo y anomos para seguir enseñando y transmitiendo conocimiento.

  6. Responder José Mª

    Muy buenas, yo también me estoy peleando con el tema de Acces para tablets, el acceso a datos lo tengo solucionado basicamente porque, de momento, tengo capacidad suficiente para tener los datos residentes en el dispositivo.
    Mi problema es de tipo visual: los formularios con gráficos se me descolocan y la presentación no se adapta a la posición de la tablet…alguna idea?
    Gracias

    • Responder Angel

      Lo tienes complicado porque Access no está pensado para adaptarse a la posición de la pantalla ni a la rotación. Mi consejo es que elijas la posición, horizontal o vertical, y diseñes los formularios para ella. Puedes abrirlos maximizados que se adaptarán un poco mejor y bloquear la rotación del dispositivo. No te queda mucho más. Otro consejo que te puedo dar es que te intereses por las PowerApps. Es otro concepto nuevo de programación, a nivel de la sencillez de access, pero esta vez adaptado a los móviles y tablets. Apunta maneras y, aunque lo tienen en fase beta, se puede probar. Yo creo que Microsoft va a acertar bien ahí y los que trabajamos con Access tendremos una salida muy buena para desarrollar en dispositivos móviles.

  7. Responder Roberto

    Hola Angel.
    Gracias por tus aportaciones. Me han dado muchas ideas que creía no eran posibles en la práctica. Es una pena que la falta de tiempo no te permita seguir publicando temás tan interesantes. No sé si sería posible que pudieras darnos unas guías sobre los aspectos técnicos que has utilizado para resolver los temas de conexiones. En especial el punto 6 que dice “Enviaremos y recuperaremos la información del servidor directamente por código, usando VBA + ADODB” y la estrategia seguida en el punto 4 “Tendremos un problema añadido que solucionar con los campos clave”. Yo tengo alguna idea pero no sé si estaré muy acertado.

    Te agradecemos de antemano tu tienpo y dedicación.

Deja un comentario

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies