There are many things a user does with an application that need to be preserved either during processing, between screens, between sessions, or between application updates/versions. When designing a system, it's important to consider what needs to be kept and where/how to do this. If designed properly, the data should also support multi-user environments.
Users are annoyed to re-enter their last specifications when the application should start with that as its default. After all, computers are supposed to remember things, right?
At the simplest level, the user's settings and can be stored in memory as global variables in VBA or TempVars. These are temporary and disappear when the application closes. However, while it's open, the program can default to those values when they should be reused.
Temporary variables and TempVars can also be used and referenced via macros.
Another way to save user preferences is to store it in the user's Windows registry. This lets you store data on a machine specific to the user for your application. It's not appropriate for saving large amounts of data that should be in a table but helpful for user selections. VBA offers a few simple commands to manage registry settings:
If you define your application name and where to store the values, you can create, retrieve, and delete your values there. Once you load them into your variables, you can apply them as you would any global variable. You'll need to make sure you define your application name to not conflict with others.
If you have a front-end/back-end split database design, storing values in the registry lets you update your front-end database without losing the user's selections.
Of course, registry settings are only stored on that machine. If the user runs your application on another machine, these settings do not exist there. If this is important, the settings should be saved in tables in the back-end database for each user, then loaded when they log-in.
Note that these functions work in all versions of Microsoft Access including 32 and 64-bit versions of Access 2010 and later.
For more advanced code using Windows API commands to manage registry entries, check our our Windows Registry VBA code in Total Visual SourceBook.
A nice thing about databases is that tables are available to store data and lots of it.
Tables can be used to save more data and may be preserved either locally or centrally. With a split-database Microsoft Access architecture where the application front-end database is linked to the shared back-end database, allows the front-end database to contain tables that are private to each user. It also supports multi-user environments without collisions.
Temporary tables can also be located here if multiple steps are necessary to complete a process, a complex report that requires multiple aggregations and selections for example. For more information about split database architecture, visit Splitting Microsoft Access Databases to Improve Performance and Simplify Maintainability
For SQL Server applications, one can use tables that are private to each user. These tables may be emptied each time the process is finished or when the application closes, or remain untouched to be available the next time the user is in the same section.
The nice thing about using tables to store user selections is that it's automatically preserved the next time the program is run. For instance, you may have a selection screen to find some data. If that form is bound to a table that's local to the user, the next time the form is opened, the last selections are preserved. No programming is required.
However, these settings disappear if a new version of your application is deployed that replaces the user's front-end copy of your database.
Anticipate that if your application is updated, you need to make sure any previously saved settings are appropriate. For instance, if your previous version allowed saving a selection that is no longer valid, you'll need to make sure that doesn't cause a problem in your new version from a data validation or security perspective.
If that is a concern, storing the data in the front-end database and deleting or resetting the values when a new version is deployed ensures previous values are not used.
Microsoft Access within an Organization's Database Strategy
How many simultaneous Microsoft Access users?
Blaming Microsoft Access instead of the Developer
Microsoft Access Version Feature Differences
Microsoft Access Versions, Service Packs and Updates
Microsoft Office 365 Access Update Version Releases
Top 14 Features Added with MS Access 2007
Taking Over Legacy MS Access Databases
Winner of Every Best Access Add-in Award
Split Database Architecture for Multiuser
Set AutoNumber Starting Number Other than 1
Avoid Unnecessary or Duplicate Indexes
Replace Attachment Field Paperclip Icon
Copy Command Button and Keep Picture
Module VBA to Forms and Controls
Subform Reference to Control Rather than Field
Suppress Page Headers and Footers on the First Page of Your Report
Annual Monthly Crosstab Columns
Add Buttons to the Quick Access Toolbar
Collapse the Office Ribbon for more space
Avoid Exits in the Body of a Procedure
Send Emails with DoCmd.SendObject
Error Handling and Debugging Techniques
Error Number and Description Reference
Remote Desktop Connection Setup
Terminal Services and RemoteApp Deployment
Missing Package & Deployment Wizard
Remove 'Save to SharePoint Site' Prompt from an Access Database
Class Not Registered Run-time Error -2147221164
Microsoft Access to SQL Server Upsizing Center
When and How to Upsize Access to SQL Server
SQL Server Express Versions and Downloads
Deploying MS Access Linked to SQL Azure
SQL Server Azure Usage and DTU Limits