Desarrollo en Microsoft Access – Por qué merece la pena y algunas consideraciones de seguridad 2

Llevo 30 años en esta profesión y trabajando con Microsoft Access desde su primera versión.

Aún no he encontrado nada que no pueda hacerse con esta espléndida aplicación de forma rápida (el diseño de formularios para la interacción con el usuario y de informes para la generación de listados es intuitivo y simple, aunque con la posibilidad de complicarlo todo lo necesario que el proyecto exija) y profesional (el ‘acabado’ de la aplicación puede simular el de un ejecutable cualquiera y el rendimiento nativo o contra bases de datos enlazadas es espectacular, siempre que esté bien programado, evidentemente).

Estas virtudes la convierten en mi aplicación de desarrollo preferida cuando se trata sobre todo de proyectos a medida de tamaño pequeño o medio o de desarrollar utilidades que se integran con otros programas, sobre todo si pertenecen a la famila Office (como Word, Excel o Outlook, por ejemplo)

En este escenario encuentro en ocasiones, clientes que o bien no disponen de Access (muchos adquieren versiones de Office SIN Access) o bien tienen una versión antigua que no es del todo compatible con el desarrollo efectuado. No hay que olvidar entonces que se puede dar una solución 100% legal y sin coste para el cliente utilizando el Runtime de Access que Microsoft pone a disposición de cualquiera. Por ejemplo, aquí tenéis disponible el Runtime de Access 2013 en español.

El runtime va a permitir la ejecución de cualquier mdb/accdb que tengáis preparado, con la ventaja (desde nuestro punto de vista como desarrolladores) de que no permite su modificación ni creación al tener las funcionalidades necesarias ‘capadas’. Además, si previamente hemos convertido nuestro mdb/accdb en mde/accde y hemos aplicado seguridad con contraseña y encriptado  a la base de datos, tendremos prácticamente la certeza de que nuestro código, formularios e informes están a buen recaudo (perdón a los gurús del software libre!).

No descartéis tampoco Access para aplicaciones de más calado. El uso de Access como front-end y SQL Server como back-end produce muy buenos resultados.

Y echarle un vistazo a las posibilidades de Access…¡para crear aplicaciones web!. La unión Acces / Sharepoint ahora que quién más quién menos dispone de un servidor virtual o dedicado en la nube, o para los recalcitrantes que aún mantenemos algunos hierros ‘de verdad’ en nuestra red corporativa, permite lograr resultados interesantes.

Y por aguantar la chapa, os dejo este enlace para bajaros un .reg que coloca la seguridad de las macros de Access 2013 (o el runtime) en bajo sin necesidad de hacerlo a través del interfaz de Access. Os será útil en caso de que vuestro código no esté firmado y lo ejecutéis mediante el Runtime de Access.

2 comentarios sobre “Desarrollo en Microsoft Access – Por qué merece la pena y algunas consideraciones de seguridad

  1. Responder jmendiburuperez@gmail.com Abr 15,2015 22:07

    Hola Antonio,

    primero perdóname por no haberte contestado a tiempo, tu comentario estaba durmiendo el sueño de los justos sin haberme dado cuenta.

    Respecto a lo que comentas, te doy mis opiniones:

    – Las bases de datos nativas (accdb) en Access 2013 no soportan los grupos de seguridad (MDW) que yo también venía usando en casi todos mis proyectos en Access 2003. No se cual es el uso que le dabas al MDW, pero en mi caso utilizaba este sistema para identificar al usuario de la aplicación, determinar a que grupo pertenecía (básicamente desarrolladores, administradores y usuarios planos ) y así establecer diferentes permisos y opciones de arranque de Access en función del grupo. También otorgaba permisos a tablas, consultas, formularios, macros y módulos en función del usuario o grupo. En cualquier caso, el método no era muy seguro, de hecho había numerosas utilidades para saltárselo.

    En Access 2013 la única alternativa en lo referente a proteger tu código es convertir las bases de datos en ficheros ACCDE (el equivalente al MDE de antes) de manera que los usuarios pueden ejecutar la aplicación pero no pueden modificarla ni acceder al código. Y si se trata de establecer distintos modos de funcionamiento según el usuario que inicie la aplicación, siempre puedes utilizar la línea de comandos de Access para pasar parámetros a la aplicación y actuar en consecuencia a través del código. Por otra parte, Access 2013 ha mejorado en el cifrado de la base de datos, de manera que es más difícil hacer ‘ingeniería inversa’ a base de ‘fisgar’ en el propio fichero. Algo es algo.

    Hasta donde yo sé, Access 2013 te permitirá trabajar con bases de datos de Access 2007 sin problema, cosa que al revés puede no ser cierto sobre todo si se usan las características más nuevas de Access 2013 (los nuevos tipos de datos en las tablas, cifrado mejorado, etc…)

    Y a la hora de adaptar las aplicaciones al nuevo Access, no he tenido problemas. Lo que si es una faena es lo que pasa con los menús antiguos, barras de herramientas o menús contextuales que tengas asociados a la aplicación o a formularios o informes, que aunque aparecen, visualmente quedan muy mal. Puedes crear nuevas cintas de opciones, pero aún estoy en ello…

    Espero haberte ayudado en algo.

    Saludos!

  2. Responder antonio Mar 2,2015 14:50

    Javier, estoy trabajando desde hace mucho con acces 2003 y me va bastante bien, quisiera adaptarla a 2013, pero no me atrevo. Dime que consejos me das. La de 2003 tengo grupo de trabajo creado y el fichero mdw (parece que hay que quitarlo).
    Puede funcionar 2013 con acces 2007 que tengo instalados en la red.

Contestar