The above uniformly fail to mention the process of simply creating an audit trail. There are two generic approaches to this. One is to simply createt he 'Audit" db with the same table structures as the 'active db'. When a record is created, updated or deleted, copy the record to the appropiate table in the audit db. In some instances, the audit tables have ddate/time and user name fields added and these are also 'filled in' when the audit record is written.
The other approach is to copy each field which is changed when ever a record is altered in any way (this includes record addition and deletion). This approach is shown as a (generically) workable function in faq181-291. PROPERLY implemented, either process should reasonably preserve any and all committed changes.
I have not posted a routine to 'rebuild' a table from the audit trail developed in the faq, however it should be a trivial exercise.
In either approach, you should take some care re the audit trail tables themselves, as they tend to grow somewhat more quickly than the actual recordset tables. I would also caution all who have sensitive data to check EXTENSIVELY with the 'net cops' to be sure the 'routine' backups are actually accomplishing a copy of the db. Win (and therefore most of the commercial back-up systems) will not copy (e.g. BACK UP) a file with any connections, so ONE individual working late or just leaving the app open duriing the back up period will generally cause the back up to skip the file. Further, the local 'net cops' are not generally inclined to review the back up log(s) or (even when they do) inform the 'owner' of the file that a back up was not successful. Add the issue of who is the 'registered' owner of the file (quite possibly -or probably- NOT the 'programmer' responsible for its care and feeding) and you can easily be 'blind sided' on hte critical date when something does go 'bump in the night'.
Other generic issues can, will and do affect your carrear path when dealing with the 'net cops', such as whn you use date/time data types in your records in the multiuser environment, you need to be assured either that the app is using the 'server time' or at least ALL the machines which access the app are FORCED to occassionally (at least DAILY) sync the clocks. I have seen at least on LARGE company where there was no thought (much less effort) to sync the clocks and found systems witth DAYS difference in the system time. Think of the trouble which could arise from a a billing soloution where one machine entered the start time and another the end time of a process. You could end up billing WAY to much -or the reverse. Neither ecpected to enhance YOUR carrear opportunities!
MichaelRed
m.red@att.net
Searching for employment in all the wrong places