Hemos hablado largo y tendido en nuestro blog de la potencia que encierra Microsoft Access a través de Visual Basic. Sin embargo no todo usuario está preparado para programar Visual Basic sobre una herramienta que, a priori, se nos vende como un entorno para crear aplicaciones dónde no es necesario programar.Vamos a intentar aportar algo de luz a un problema que surge cuando los datos no residen en el mismo fichero Access sobre el que estamos desarrollando las consultas, formularios e informes que interactuarán con dichos datos.
Cuando se nos presenta ese caso Microsoft Access dispone de un asistente que, con cuatro pasos muy sencillos, nos va a permitir decirle dónde se encuentran los datos, y Access creará un vínculo con los mismos de forma que, a la vista, es como si los datos estuvieran en el propio Access. Lo único que cambia es el icono de las tablas que nos indica que los datos están en otro lugar, pero a nivel de desarrollo todo sigue igual y podemos seguir diseñando formularios de la misma forma que si los datos estuvieran en el mismo fichero.
Entonces, si Microsoft Access lo hace tan sencillo ¿cuándo y por qué tengo que variar el método de acceder a dichos datos?, ¿por qué mencionamos programación en Visual Basic?
Aunque la respuesta pudiera resultar sencilla de responder realmente intervienen cientos de factores que nos van a determinar el cómo debemos hacerlo. Sigamos desgranando el problema donde daremos unas pautas sencillas para decidir qué hacer, y cómo.
La ubicación y el medio para conectar a los datos es determinante
¿Dónde están alojados esos datos a los que queremos acceder?, ¿qué tecnología usaremos para conectarnos a ellos? La respuesta a esta pregunta ayudará a determinar qué debemos hacer.
Todo depende de dónde estén alojados los datos y, en gran medida, de los medios tecnológicos disponibles a través de los que nos comunicaremos con ellos.
Datos en ubicación local
Pongamos por caso de que los datos están en el mismo ordenador desde el que estamos desarrollando nuestro programa, y en un fichero Access distinto al que estamos usando para crear los formularios. Lo único que separa nuestro programa de los datos es la posición dentro del disco duro, y los discos duros actuales son bastante rápidos. O sea, que acceder a ellos desde el mismo ordenador será lo suficientemente rápido como para que las “Tablas Vinculadas” de Access los pueda manejar con soltura.
Datos en otro ordenador de la misma red interna
Este segundo caso tampoco suele ofrecer problemas. Tenemos varios equipos dentro de la red interna y los datos están alojados en otro ordenador que no es el nuestro, sin embargo, estas redes internas suelen estar cableadas y su velocidad, así como la estabilidad del acceso a los datos, es muy fiable. Es raro que fallen los cables. Así que aquí tampoco sería un problema usar “Tablas vinculadas” en Microsoft Access. Si la red interna está bien construida Microsoft Access accederá a los datos con suficiente soltura.
Datos alojados fuera de la red interna con acceso mediante Internet
Aquí ya nos metemos en un terreno farragoso. En este caso nos podemos encontrar con las limitaciones propias de la velocidad inestable de las líneas de internet. Puede que queramos conectarnos a los datos alojados en otra sede situada, por ejemplo, a 100km de distancia de la nuestra, y la única vía de acceso a ella sea mediante la conexión a internet que tenemos contratada.
¿Nuestra línea de internet es rápida?, ¿es estable?, ¿tiene cortes?, ¿ADSL, Fibra, 3G, 4G? La estabilidad y velocidad de la línea determinarán el éxito o un fracaso rotundo a la hora de acceder a los datos.
En el momento de escribir este artículo, en España, hay una creciente cantidad de usuarios que acceden a la red a través de Fibra Óptica con velocidades que llegan incluso hasta los 300Mb simétricos. Sin embargo, aún quedan muchísimos lugares dónde esta tecnología no llega, ni se le espera en los próximos años. Incluso en Polígonos industriales dónde se concentran gran cantidad de empresas no se dispone de Fibra Óptica. Por desgracia aún quedan muchos lugares en España donde, lo máximo a lo que se puede aspirar, es a un ADSL de 10Mb de bajada con 1Mb de subida.
Las líneas móviles, nuestros teléfonos, que también nos permiten compartir su conexión a internet con nuestros portátiles podrían darnos acceso a los datos alojados en otra ubicación cuando nuestro trabajo no dependa de un puesto fijo. Volvemos a lo mismo, no siempre la cobertura es la adecuada y, aunque en España ya se ha impuesto el 4G, no todas las zonas disponen de dicha cobertura, en muchos casos se conectan a la red 3G, y a veces, ni eso, provocando caídas en el tráfico de datos, cortes, lentitud de navegación y problemas varios que perjudicarán enormemente el vínculo que hayamos creado a nuestros datos.
De los tres ejemplos simplificados que hemos expuesto, pues hay muchos más de los que podríamos hablar, este último, es con diferencia el que nos hará cambiar la forma en la que debemos acceder a los datos.
La inestabilidad, velocidad y rendimiento de la línea harán que las “Tablas Vinculadas” de Microsoft Access no respondan tan bien como en los dos primeros ejemplos. De hecho es que en el 100% de los casos las “Tablas vinculadas” de Access no son tan eficientes como conectarse a los datos mediante Visual Basic. Lo que ocurre es que en según qué condiciones, y puestos en una balanza, si la velocidad y estabilidad para acceder a los datos es buena, esa carencia que tiene el propio Access se compensará con la indiscutible facilidad de desarrollar nuestro programa usando “Tablas Vinculadas”.
Visual Basic contra tablas vinculadas
Lo hemos dejado claro, las “Tablas vinculadas” no son todo lo eficientes que debieran y eso es un hecho constatable. Prueba a vincularte sino a una tabla alojada en la otra punta del mundo y verás como Access, a pesar de mostrarte los datos, no se moverá con la misma soltura que lo habitual. Visual Basic para conexiones externas aporta más velocidad y estabilidad al tráfico de datos que las tablas vinculadas, por el contrario, para el usuario menos avanzado es tremendamente complejo programar pues hay que escribir código para conectarse al servidor, código para pedirle los datos, código para filtrarlos, código para editar, añadir o actualizarlos. Todo se ha de escribir en Visual Basic y con ello perdemos el 90% de las bondades que tiene Access respecto a su facilidad de uso. Todo se vuelve más complejo y enrevesado pero tremendamente eficiente.
Y aquí es cuando los usuarios de Microsoft Access se desmoronan ¿no es Access una herramienta para usarla sin conocimientos de programación? Si, lo es, pero depende de lo que pretendas hacer con ella.
¿Debo abandonar mi proyecto Access en estos casos si no se programar? Ni mucho menos, no debes, es más, te animo a que te adentres en este nuevo escenario y te voy a dar un motivo muy poderoso con el que pretendo convencerte. El problema al que nos hemos enfrentado en los tres casos descritos, de los cientos que podríamos haber expuesto, no es un problema de Microsoft Access sino del resto de tecnologías que nos deben permitir llegar hasta los datos allí donde estén. Por ello, aunque busquemos una alternativa a Microsoft Access para nuestro desarrollo, todas se encontrarán con el mismo problema y, a día de hoy, todo pasa por usar código de programación, da igual que sea Visual Basic, C++, C#, JavaScipt, Python, etc.
Access sólo ofrece Visual Basic, y realmente no necesitamos más. Visual Basic de Microsoft Access es suficientemente potente y nos ofrece todas las herramientas necesarias para acceder a nuestros datos, estén donde estén, de forma eficiente.
En los próximos artículos de esta serie nos adentraremos precisamente en este nuevo escenario. Veremos cómo configurar la conexión a los datos, como pedirle registros al servidor y como interactuar con ellos. También aprenderemos algunas peculiaridades, de las que no suelen venir en los manuales, y que te facilitarán la vida.