Access – Conectando nuestra aplicación a bases de datos SQL Azure

Anteriormente hemos hablado en este blog sobre dónde podemos tener los datos a los que se conecta Access para interactuar con ellos, de aquí en adelante vamos a escribir una serie de artículos donde veremos paso a paso como conectar nuestra base de datos a una serie de tablas que estarán alojadas en un servidor SQL Azure.

¿Por qué SQL Azure?

Podría ser cualquier servidor  de bases de datos como SQL Server, MySQL, Oracle, etc. He decidido usar SQL Azure porque me parece una opción bastante económica a tener en cuenta, además es exclusiva de la nube, o sea que no tendremos los datos alojados en nuestra intranet, y esto nos va a permitir desarrollar los siguientes artículos teniendo en cuenta una perspectiva y un dilema con el que nos encontramos los programadores de Access una vez saltamos de los datos en local a trabajar con datos en la nube.

Windows Azure

¿Tablas vinculadas o formularios desconectados?

Menudo dilema al que nos tenemos que enfrentar. No hay una norma escrita aunque si unas buenas prácticas. Yo os voy a hablar desde mi experiencia particular y sobre ella vamos a intentar discernir la opción mas correcta.

Supongamos que estamos trabajando en una intranet, los datos los tenemos alojados en un servidor SQL Server de nuestra red, imaginemos que todos los ordenadores, incluido nuestro servidor, tienen cableadas todas las conexiones de red. Damos por hecho entonces de que tenemos una instalación muy estable y rápida y que dentro de nuestra instalación podemos mover ficheros de los equipos clientes al servidor con soltura. En nuestro ejemplo, tenemos un fichero de datos Access en el servidor y el resto de los equipos de nuestra red otro programa Access con los formularios, informes y demás opciones conectado directamente al fichero Access del servidor, que es quien tiene los datos. En este entorno tan estable y rápido podemos permitirnos el lujo de usar tablas vinculadas y seguir disfrutando del diseño y la programación de Access tal y como lo conocemos. La única diferencia es que los datos estarán en otro ordenador.

Access tablas vinculadas

Vamos a simular ahora otro entorno, imaginemos el mismo programa de antes pero ahora los datos los tenemos en la nube, podemos acceder a ellos a través de Internet pero, para complicar un poco más las cosas, ni siquiera tenemos una conexión estable a Internet, bien porque la wifi no es buena, bien porque nuestro proveedor de Internet nos ofrece una velocidad penosa o, por rizar el rizo, porque estamos usando la conexión a Internet de nuestro teléfono móvil, la cual no es nada estable, ni fiable en determinadas zonas. En este entorno tan distinto al anterior  tenemos que cambiar la forma en la que nos conectamos a los datos e intentar usar lo menos posible las tablas vinculadas, veamos por qué.

Desventajas de las tablas vinculadas

Las ventajas de usar tablas vinculadas ya las sabemos, no afecta a nuestra forma de usar Access pero implican otra serie de desventajas entre las que debemos destacar:

  • Para operaciones de consulta de datos no suelen dar problemas pero con operaciones de edición de datos, inserción o eliminación pueden volverse bastante lentas.
  • Los datos son fácilmente corrompibles si tenemos en cuenta que una operación como la anteriormente citada lleve su tiempo y nos falla la conexión mientras tanto.
  • Las tablas vinculadas dejan pistas sobre los datos de acceso al servidor que un usuario mal intencionado puede utilizar para estropearnos algo.

Si nuestra aplicación es de consulta de datos nada más, Access puede recuperar los datos desde el servidor sin mayores complicaciones y sin llevarse mucho tiempo, solo tendremos que tener las precauciones necesarias para pedirle únicamente los datos que queremos consultar y optimizar los registros que tienen que viajar desde el server a nuestra aplicación.

Si nuestra aplicación va a llevar operaciones complejas de anexado de datos, ediciones masivas o eliminaciones de registros y disponemos de un entorno hostil, en cuanto a calidad de la conexión, debemos plantearnos realizar esas operaciones a través de código VBA donde podremos optimizarlas mucho mejor y comunicarnos directamente con el Servidor para darle las órdenes pertinentes.

Mientras estamos editando los registros, si se produce un corte en la conexión a Internet, podremos encontrarnos con desagradables sorpresas y se pueden corromper fácilmente los mismos. Por ello es recomendable traer del servidor única y exclusivamente los registros que necesitamos, así estaremos minimizando el riesgo. El proceso sería: Conectamos al server, le pedidos el registro, desconectamos del server. Trabajamos con el registro, conectamos al server y lo actualizamos, desconectamos otra vez.

Por otro lado, cuando trabajamos con tablas vinculadas estamos dejando un rastro para que un usuario más avanzado pueda descubrir el usuario y la contraseña de acceso al servidor, dejando con ello nuestra seguridad en peligro, aunque hay medios para poder ocultar las tablas de Access.

¿Que ventajas ofrece comunicarse directamente con el servidor?

En primer lugar, como hemos comentado, no tener que dejar a la vista las tablas vinculadas y datos de seguridad pues todo se realiza a través de código VBA el cual es mas inaccesible.

En segundo lugar podemos optimizar muchísimo mejor las operaciones de modificación de registros o inserción de registros o incluso eliminación enviando la orden directamente al servidor. Se gana bastante tiempo al realizar estas operaciones por VBA.

¿Que me supone tener que programar?

Querido lector/a esta es la parte más desagradable de este artículo que te estoy escribiendo. Ya te adelanto que fácil no es, tendrás que salir de la zona de confort que nos permite Access. Si eres un usuario básico de Access, de los que, hasta ahora, habías podido desarrollar todos tus programas utilizando los asistentes, y vinculando formularios a tablas y consultas como si nada, a partir de aquí todo cambia, cuando hablamos de programar es programación pura y dura, ¿Pero Access hace eso? por supuesto, y más, mucho más. A partir de aquí es necesario que el lector disponga de unos conocimientos algo más avanzados y haya usado VBA.

microsoft-access-vba-prgramming-vbe

¿Que viene después de este artículo?

Como es casi imposible desarrollar en un solo artículo toda la problemática con sus complejidades y demás pormenores, iremos desarrollando en varios de ellos todo el proceso, a partir de aquí veremos:

Solo os pido paciencia

Todo esto conlleva mucho trabajo y no dispongo de todo el tiempo del mundo para ello. Poco a poco iremos desarrollando todos estos artículos que nos llevará algún mes que otro. Solo os pido un poco de paciencia y tendréis un contenido de incalculable valor con el que vuestras aplicaciones podrán dar un salto estratosférico pudiendo trabajar en la nube, tan de moda ahora.

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.

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