Hi Peter,
Somewhat ironically, we were just writing the data to another set of tables that, in theory, could be just as likely to become corrupted as the original. They were not exact mirror tables in terms of structure, though. It just had a header table storing who made changes, what time, from what computer, using what logon (etc) and then joined via uniqueid to another table that had field name, old val, and new val. With this technique, you really need to have a regular archiving plan of some sort too. Depending on the amount of data you have & the number of users making changes you have, those change tracking tables can really take off size-wise. Again, another reason to analyze the business needs & see what's required.


>>I've shared this on here before, but it applies again here. At a previous employer we used triggers to track the changing of all fields. Old values and new values were stored.
>
>Glad you mentioned that approach which I had forgotten. We ARE going to upsize to SQL and probably sooner rather than later. I would be more willing to do the trigger approach with SQL than with FoxPro local tables.
>
>How did you store your values? In a table? Sequential file?
>
>Did you identify each field: Database!Table.Field along with the old and new values?
>
>I imagine the next step is to have a roll-forward technique from the last good backup.
>
>Perhaps SQL offers this already.
>
>SQL Server is reliable because of the enforced transaction logging in all versions of SQL Server, complete with roll-forward and roll-backward recovery. Recovery from application and system errors and from hardware problems has always been a solid part of the Windows NT/SQL Server cohesiveness.
>
>Another new feature in the hardware/software combination arena is the fallback support in SQL Server. This option lets two servers share one disk tower. If one server fails, the other can be brought up very quickly.
>http://www.windowsitlibrary.com/Content/77/01/1.html
>
>Also http://www.dbazine.com/sql/sql-articles/mullins-sqlserver
>
>Peter