Microsoft Access Developer Center

Table Design

Query Design

Form Design

Form Tips and Mistakes

Module VBA to Forms and Controls

Form Navigation Caption

Using a RecordsetClone

Synchronize Two Subforms

Multiple OpenArgs Values

Late Bind Tab Subforms

Subform Reference to Control Rather than Field

Tab Page Reference

Shortcut Keys


Combo Box Top Tips

Properties and Validation

Select First Item

Cascading Combo Boxes

Zip, City, State AutoFill

Report Design

Suppressing Page Headers and Footers on the First Page of Your Report

Add the NoData Event

Annual Monthly Crosstab Columns

Design Environment

Adding Buttons to the Quick Access Toolbar

Collapsing the Office Ribbon for more space

VBA Programming

Basics: Forms and Controls

Using Nz() to Handle Nulls

Avoiding Exits in the Body of a Procedure

Shortcut Debugging Keys

Setting Module Options

Math Rounding Issues

Rename a File or Folder

Avoid DoEvents in Loops

Age Calculations

Weekday Math

Sending Emails with DoCmd.SendObject

Source Code Library

Microsoft Access Modules Library

Microsoft Access Modules

VBA Error Handling

Error Handling and Debugging Techniques

Error Number and Description Reference

Basic Error Handling

Pinpointing the Error Line

Performance Tips

Linked Database

Subdatasheet Name

Visual SourceSafe

Deployment

Runtime Downloads

Simulating Runtime

Prevent Close Box

Disable Design Changes

Broken References

Remote Desktop Connection Setup

Terminal Services and RemoteApp Deployment

Reboot Remote Desktop

Missing Package & Deployment Wizard

Avoid Program Files Folder

Microsoft Access Front-End Deployment

System Admin

Disaster Recovery Plan

Compact Database

Compact on Close

Database Corruption

Class Not Registered Run-time Error -2147221164

Inconsistent Compile Error

Decompile Database

Bad DLL Calling Convention

Error 3045: Could Not Use

Converting ACCDB to MDB

SQL Server Upsizing

Microsoft Access to SQL Server Upsizing Center

Microsoft Access to SQL Server Upsizing Center

When and How to Upsize Access to SQL Server

SQL Server Express Versions and Downloads

Cloud and Azure

Cloud Implications

MS Access and SQL Azure

Deploying MS Access Linked to SQL Azure

Visual Studio LightSwitch

LightSwitch Introduction

Comparison Matrix

Additional Resources

Microsoft Access Help

MS Access Developer Programming

More Microsoft Access Tips

Technical Papers

Microsoft Access Tools

Connect with Us

Email NewsletterEmail Newsletter

FMS Development Team BlogDeveloper Team Blog

Facebook PageFacebook (Feed)

Twitter with FMSTwitter

FMS Support SiteSupport Forum

 

Microsoft Access ProductsMicrosoft Access Database Architecture: Storing Temporary Data and User Settings

Provided by: Luke Chung, President of FMS, Inc.

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.

Problem

Users are commonly annoyed to be forced to re-enter their last specifications when the application should start with that as its default. After all, a computer is supposed to be good at remembering things, right?

Keeping Selections in Memory for the Current Session

At the simplest level, the user's settings and can be stored in memory as global variables in VBA. These are temporary and will disappear when the application closes. However, while it's open, the program can default to those values if they should be used again.

Temporary variables, TempVars, introduced in Microsoft Access 2007 can also be used and referenced via macros.

Using the Registry to Store User Information Between Sessions

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 you would expect in a table but helpful for user selections. VBA offers a few simple commands to manage registry settings:

  • GetSetting(appname, section, key[, default])
  • SaveSetting appname, section, key, setting
  • DeleteSetting appname, section[, key]

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.

Issues with Storing Data in the Registry

If you have a front-end/back-end split database design, storing values in the registry lets you update your front-end database without wiping out the user's selections.

Of course, registry settings are only stored on that machine, so if the user runs your application from another machine, these settings will not exist for them. 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.

32 and 64 Bit Support

Note that these functions work in all versions of Microsoft Access including 32 and 64-bit versions of Access 2010 and 2013.

For more advanced code using Windows API commands to manage registry entries, check our our Windows Registry VBA code in Total Visual SourceBook.

Using Private Tables to Store Information Between Sessions

A nice thing about databases is that tables are available to store data and lots of it.

Split Database Design with Temporary Tables in the Front End

Tables can be used to save more data and may be preserved either locally or centrally. In Microsoft Access, the common use of Jet databases with the application database for each user linked to the central data database, allows the front-end database to contain tables that are private to the user and 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 will disappear if you deploy a new version of your application that replaces the user's front-end copy of your database.

Making Sure Previous Values Remain Valid

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 will ensure previous values are not used.