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.
A common example is the use of a Customer table where a Customer ID field identifies the record, which contains the person's name, address, etc. An invoice table could include a Customer ID that identifies the customer. While this approach works if the address changes; the Customer record is updated and all his/her invoices reflect the new address; a problem arises if there's a need to go back and find out where a previous shipment was sent. If a backup of the original customer record or the original customer data is not maintained with the original invoice, that information is lost.
While some information may not be worth keeping, old phone numbers for example, other pieces could be critical. For instance, a list of products and prices can be used for new sales, but a copy of the data needs to be kept in the invoice's line items so that a change in the prices does not cause old invoices to change. Thinking about what is important and is not is a crucial part of the design process, and very difficult to fix later.
One way to address this is to make a copy of the original customer record in the invoice table. This essentially takes a snapshot of the data and preserves it, making it easy to access the old invoice and see exactly what data was used at the time of creation or shipment.
Another approach is to presume the data does not change that often and when you reprint the invoice you want to show the new address, not the old one. If that's the case, this could be solved by simply keeping a shadow Customer table, so that any changes to the customer record (or relevant fields) are documented along with the time and user who did it. If historic information is required, it would be a simple search in the table to find it.
A shadow table is essentially the same as the original table with some small differences:
One can then create a simple parameterized query that takes all the fields from the master table and inserts it into the shadow table for a particular record (e.g. InvoiceID).
Then, but adding VBA code to form's AfterUpdate event, the query can be invoked with the current record's ID to copy the record to the shadow table.
In SQL Server, a trigger can be created for each table to automatically store a copy in another table. This is more robust since any time the data is modified, this audit record is created. In Access using Jet tables, this is less robust since people may be able to edit the records without going through your data entry form.