5 Types of Settings for Microsoft Access Applications
Settings fall into one of five major categories based on their scope:
- Program-specific
- Tenant-specific (a.k.a., Client-specific)
- Machine-specific
- User-specific
- Session-specific
Let's explore each type further with a brief description, a few examples, and appropriate places to store the associated settings.
Program-Specific Settings
These are settings that apply across an entire Access application. They are the same for every client/customer, every machine, and every user.
Examples
- Program Version
- Default MsgBox Title
- URL to online documentation
Where to Store
- Local table
- Database property
- VBA
Const
Tenant-Specific Settings
These are settings that apply to a specific client or customer. Critically, these types of settings apply to ALL users and ALL workstations that belong to a client.
Examples
- Network folder path
- Next available check number
- SQL Server connection information
Where to Store
- Back-end database
- Network folder
- Local table (for a small number of clients; does not scale well)
Machine-Specific Settings
These are settings that should apply to all users on a single machine.
In all honesty, I rarely use these types of settings. Most settings make more sense as either tenant-specific or user-specific. Also, saving settings to the HKLM hive requires admin permissions, so that's something that's only practical to do at install time. Note that reading settings from HKLM DOES NOT require admin privileges. So you can write settings to HKLM as part of your installer and then read those settings from within VBA.
Examples
- Single-machine license key
- Template folder
- Export/import folders
Where to Store
- HKLM registry hive (via installer...HKLM requires admin permissions)
%ProgramData%
folder (hidden folder that non-admins may Modify; e.g.,C:\ProgramData\MyApp\
)- Public Documents folder (visible folder that non-admins may Modify; e.g.,
C:\Users\Public\Documents\MyApp\
)
User-Specific Settings
These settings represent personal preferences. They should be stored in a user profile area. That way, if two users are sharing the same machine, the personal preferences of one user will not overwrite the preferences of another.
Examples
- Size and position of forms
- Default zoom level for reports
Where to Store
- HKCU registry hive (via
SaveSetting
/GetSetting
) - My Documents folder (e.g.,
C:\Users\Mike\Documents\MyApp\
) %AppData%
folder (e.g.,C:\Users\Mike\AppData\Roaming\MyApp\
)- Backend database settings table linked to a user table (this makes sense only if users run the program from multiple workstations)
Session-Specific Settings
These are settings that reset every time you close and open a program. They are good for activities that a user may do repeatedly during a single session of using the program, but that wouldn't necessarily make sense to save between sessions.
The most common example of this from my own applications is report criteria. If your user is running one report for the last quarter, there's a good chance she'll want to run other reports for the same time period. However, the next time she opens the program, she may be more interested in running reports for the past year or the prior month.
Examples
- Starting and ending report dates
- Form filter criteria
- Report filter criteria
- Last used save directory for exports
Where to Store
Cover image created with Microsoft Designer; image by Stefan Schweihofer from Pixabay