Guardar la configuración y las preferencias de los usuarios en la base de datos de Microsoft Access

Microsoft Access proporciona varias estrategias efectivas para guardar la configuración y las preferencias de los usuarios, asegurando una experiencia personalizada mientras mantiene la integridad de los datos en sesiones y dispositivos. En este artículo exploraré algunos de los métodos posibles que podemos usar para almacenar la configuración específica del usuario y en toda la aplicación en las bases de datos de acceso.

Configuración, ¿qué configuración?

Estos son solo algunos ejemplos de los tipos de cosas que uno podría almacenar para un usuario de acceso:

• Posicionamiento de formulario
• Filtros predeterminados
• Orden de columna de hoja de datos, tamaños y visibilidad
• Formato de exportación predeterminado y ruta de salida
• Colores, fuentes, …
• Impresora predeterminada
• Lenguaje de preferencia
• etc…

Uso de una tabla dedicada en la base de datos

Un enfoque común es crear una tabla dedicada, como ‘Usersettings’, dentro de la base de datos de acceso para almacenar preferencias específicas del usuario. Luego, cada configuración se almacena como un registro dentro de la tabla y se puede realizar fácilmente las operaciones de acceso y CRUD.

En tal escenario, tiene sentido crear un par UDF, como: UserSetting_Get (), UserSetting_Set () y UserSetting_Delete () para aliviar el trabajo con la configuración.

Este enfoque garantiza que la configuración persista incluso después de las actualizaciones de front-end o al cambiar de dispositivos, siempre que la base de datos de back-end permanezca accesible.

Incluso puede implementar la sincronización local de los datos de back-end si así lo desea, por motivo de rendimiento, pero normalmente, si tiene las mejores prácticas establecidas y una conexión persistente, el rendimiento no debería ser un problema.

Archivos de configuración

La configuración también se puede guardar en los archivos de configuración (INI, .dat, .json) almacenados localmente o en un servidor. Estos son leídos por la aplicación front-end durante el tiempo de ejecución.

Para la optimización del rendimiento, configuro mi script para buscar localmente para el archivo de configuración, no se encuentra, luego busco en el servidor y lo copio localmente (para todas las llamadas futuras). Además, cuando leo el archivo, lo leí a una variable VBA para que permanezca en la memoria durante la duración de la sesión, por lo que solo necesito leer el archivo una vez y todo se hace a partir de entonces en la memoria.

El inconveniente de este enfoque es que si no toma ciertos pasos de seguridad, los usuarios podrían meterse con los archivos.

Registro

El almacenamiento de información en el registro es otra opción para guardar las preferencias del usuario y Microsoft Access tiene comandos incorporados para hacerlo: SaveSetting, GetSetting, GetAllSettings, DeleteSetting.

El principal inconveniente aquí es que no es portátil en todos los dispositivos a menos que se sincronice manualmente

Puede obtener más información sobre cómo trabajar con el registro en mi artículo:

Pensamientos finales

No hay talla única aquí, cada enfoque tiene pros y contras y su uso depende de su configuración y necesidades.

En todo caso, desde el punto de vista de rendimiento, siempre es mejor leer los valores solo una vez y luego almacenar la información en la memoria (variable VBA, tempvar) en lugar de hacer una llamada repetida para recuperar la información una y otra vez.

Una cosa que destacaría para cualquiera de estos es que para un entorno típico sea bueno, pero si planea almacenar cualquier información peligrosa o sensible potencial, ¡asegúrese de cifrar primero los datos!