Walter,

When I need that I use an audit trail table. The most complete audit trail I ever built was for a company in NYC. We used a table with three memo fields adn timestamp and user id field. When a use modified a record we did an AFIELDS() and saved teh resulting array into one memo, then we saved the original data into another memo and finally we saved the changed data into the third memo. The date fiedl was the date of edit and the suerid was the login account that made the changes.

This approach allowed us to write code that could temporarily set the system back to any point in time bay backing up through the audti records and when the user was finished seeing what they wanted we could advance the system back to today. It wasn't easy to do, but the client needed it adn so we built it.

But the approach you are speaking of isn't redundant data the history data has a different purpose for existing than the curretn data does and that's causes teh domains to be different. For example, a user changes the name field, now the current table has "The Current Name for the customer" the history table (or record) has "The name for the customer at the stamped point in time". The two definitions are different so the two attributes are different attributes and there is no redundancy, no violation of Normalization.

I might argue with using the same table for both current and history, but that would be an implementation discussion.

This would be an example of what I said in a previous message, that often I hear a developer talk about normalization being a burden because of ... only to discover that the issue was a non-issue and normalization woudl not require the structure the way the developer had thought it would.

Normalization is not ONLY data in one place, it is also data in the right place.