When designing an application and its tables, it’s very important to capture the time dimension and determine how data should be stored with the expectation that it will change over time. While there’s a natural tendency to keep data normalized so that the same information is stored in only one place, the time dimension also needs to be considered.
What Needs to be Preserved Over Time?
Making Sure Data Normalization Doesn’t Lose Historical Data
FMS developer Molly Pell is a guest blogger on the Microsoft Access developer blog. This post demonstrates a neat trick that you can use to filter a Continuous or Split form while your users are typing in a Combo Box.
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?
Solutions
There are several ways to preserve user information during a session, on a PC, and/or between PCs:
Keeping Selections in Memory for the Current Session
Using the Registry to Store User Information Between Sessions
Using Private Tables to Store Information Between Sessions