There are seperate 'schools' of thought on audit records. An alternative to saving hte entire record prior to each change is to save only the changes. In instances where there is considerably more edit activity than add / delete activity, this is somewhat less 'expensive' (in storage at least) than simply copying the record (along with tthe who-done-it info). See faq181-261 for an example of the alternative.
Otherwise, pay heed to points made by DrSimon. ?they are valid considerations. In particular, hte 'audit' table growth is (or at least CAN be) awesome and left unchecked will rapidly impact the performance of the primary app (and not in a good way). I generally prefer to copy aduit records of inactive records to a seperate historical / archive table than their actual (total) deletion. In the apps where I have implemented this, there was a clear indication that a (primary table) record was inactive, so I could easily copy it to the archive db, delete it from the 'primary' record table and then do hte same with the 'audit' records. Even with this, it was necessary to create new 'archive' databases periodically.
MichaelRed
m.red@att.net
Searching for employment in all the wrong places