Preparar una aplicación Access para su distribución comercial

Me pregunta por correo Federico, cómo actuar para convertir una aplicación que ha desarrollado en Access en un ejecutable. Copio aquí mi respuesta porque creo que puede ser útil para cualquiera que pudiera estar en la misma situación:

Estimado Federico:

Access no puede convertirse en un ejecutable de verdad. No hay una herramienta que lo transforme en un EXE. Lo que si puedes (y debes) es proteger lo más posible tu desarrollo y darle la apariencia de una aplicación NO Access. Esto lo consigues con varias estrategias. Es una tarea laboriosa, a base de probar/fallar/corregir hasta conseguir un aspecto y funcionalidad prácticamente igual al de un ejecutable, pero su puede lograr. Te comento las cosas que tengo en cuenta habitualmente:

  • Si no lo has hecho ya, mueve las tablas a un accdb diferente y protégelo con contraseña. Luego, enlaza las tablas al accdb de tu aplicación. Cualquier aplicación profesional en Access debe separarse siempre en dos: el back-end con las tablas y el front-end con la aplicación en sí que enlaza las tablas del back-end.
  • Si no lo has hecho, haz un buen control de errores en la aplicación. ¡No te puedes permitir que ante un error, Access intente mostrar el código VBA erróneo! Aprovecha para volcar a un fichero de log cualquier error que se produzca de forma inesperada. Te ayudará a depurar el programa.
  • En el accdb de tu aplicación tienes que ejecutar código nada más iniciar para poder distinguir si estás iniciando la aplicación en modo de ‘usuario’ o en modo de ‘desarrollador’ y ocultar/mostrar o habilitar/deshabilitar ciertos aspectos de Access. En modo ‘usuario’ querrás ocultar todo lo que muestra Access habitualmente salvo tu propia cinta de opciones (ribbon) o menú desde el que abrirás los formularios e informes de tu aplicación. Nunca muestres la ventana de objetos de Access. Se puede y debe ocultar. Utiliza un menú para abrir tus formularios o informes. En modo ‘desarrollador’ querrás ver tu Access al completo con su aspecto ‘normal’ para desarrollar de la forma habitual.
  • Para ejecutar código en el momento de inicio debes crear una macro llamada ‘Autoexec‘, indicar en la misma que quieres ejecutar código y escribir el nombre de una función VBA a ejecutar, por ejemplo ‘LanzarApp()’.
  • Para informar a tu aplicación si debe iniciarse en un modo u otro, puedes crear un acceso directo al accdb de la aplicación, lo editas y añades al final la opción /cmd y detrás un texto o un par Texto=Valor, en definitiva algo que quieras usar para distinguir el modo.
    Por ejemplo: ‘TuAplicación.accdb /cmd ModoUsuario’ o ‘TuAPlicación.accdb /cmd Modo=Usuario’. Insisto, el texto tras /cmd es el que tú quieras. Luego lo recuperarás desde VBA y actuarás en consecuencia.
  • Para acceder al texto que has puesto tras /cmd en tu aplicación, usas la función Command() de VBA en la función ‘LanzarApp()’ que te lo devolverá tal cual. Lo procesas y determinas el modo de inicio.
  • En función del modo, escribes código VBA en la función ‘LanzarApp() ‘ que hemos comentado para:
    • Ocultar o mostrar los elementos de Access como tablas, consultas, formularios, macros, informes, código, barra de estado, etc. Usa la función SetHiddenAttribute para que el objeto se oculte o se muestre en Access.
    • Forzar el modo de trabajo, para, por ejemplo, ocultar la ventana de objetos de Access, usar pestañas o no, establecer el título de la aplicación, el icono, menús y cinta de opciones, macros de captura de teclas, etc…Para esto se usan instrucciones VBA como Currentdb.Properties, Application.GetOption, Application.SetOption y docmd.ShowToolBar. Si buscas en Internet, encontrarás ejemplos.
    • Crear macros de teclas especiales para evitar que cumplan su función, es decir, atrapar las combinaciones de teclas que no quiero que tengan la funcionalidad en mi aplicación que habitualmente da Access (como F1, por ejemplo, para mostrar la ayuda)
    • Abrir (si se requiere) el formulario inicial de la aplicación.
  • Con esto voy cambiando el aspecto de la aplicación, ocultando elementos típicos de Access y mostrando principalmente elementos de mi aplicación. Cuando ya veo que todo esto funciona como quiero, y que mi aplicación, en modo ‘usuario’ tiene ‘casi’ el aspecto de una aplicación no Access, genero la aplicación en formato ACCDE. En este formato, el propio Access impide modificar formularios, informes, macros y código, con lo cual queda bastante protegida. NUNCA debes instalar versiones ACCDB de tu aplicación a tus clientes, siempre versiones ACCDE.
  • Por último, al instalar en el domicilio de un cliente hay que usar SIEMPRE el runtime de Access y nunca la aplicación normal de Access. El runtime es una versión ‘capada’ de Access que Microsoft permite bajarse de su web y usarla legalmente en cualquier instalación. El runtime limita aún más las cosas que un usuario puede hacer con la aplicación. Si el cliente ya dispone de una licencia de Access y no puedes instalar el runtime sin afectar a otros usos de Access que pueda estar haciendo el cliente, siempre puedes obligar a un Access ‘normal’ a que se comporte como el runtime, usando la opción /runtime en la línea de comandos.
  • Siempre hay que confirmar que la aplicación se comporta como esperamos cuando se usa el runtime. Ten en cuenta que los menús contextuales y otras cosas no están disponibles en el runtime y los tienes que preparar antes.

Como ves, son un montón de detalles, pero te digo por experiencia (comercializamos aplicaciones en Access) que puedes llegar a conseguir la apariencia y funcionalidad de un EXE y aprovechar a la vez todas las ventajas que te ofrece Access.

Otra cosa que te puede ayudar mucho a la hora de comercializar tu aplicación Access es moverla a la web. Es un tema económicamente costoso pero muy simple desde el punto de vista técnico si ya tienes una aplicación en marcha con las pautas que te he dado. Se justifica sólo en caso de que explotes tu aplicación comercialmente, pero se compensa simplificando al 100% su distribución e implantación porque sencillamente, ya no es necesaria. Los clientes acceden a tu aplicación por un navegador, sin ningún tipo de instalación en su domicilio y listo. Pero, insisto, es un tema con cierto precio por alquiler de infraestructura en la nube, licencias por usuario concurrente, consultoría, etc.

Espero haberte ayudado.

Contestar