>Paul,
>
>>FoxAudit should make this pretty easy
>
>Do you take any kind of performance hit with FoxAudit?
>
>By your last post to Marcus, it sounds pretty easy to undo a batch process. Is that the case? To solve Marcus' problem, I've been creating batches with unique keys, and adding a 'batchkey' field to my tables. Then I can just delete all records with that batch number if there is an issue. But the FoxAudit idea sounds like it may be better. I'd appreciate your thoughts.
>

I haven't had the opportunity to use FoxAudit. It has come up over the past few years on various projects I've worked on, but so far we haven't used it (for various reasons, none of which was because of the technology). From what I have seen, though, it's just a trigger that fires on inserts/deletes/updates that logs the changes into an audit table. I'd guess that this is reasonably fast, but you would definitely take a hit if you were doing a ton of changes. If it was a problem, I think you can just disable it. I think for most applications the performace hit is minimal and acceptable for the features it adds.

This kind of thing really has a lot of potential uses. Imagine being able to let your users "undo" a month-end process that adds a bunch of records, changes a number of others, etc., just by selecting a menu option. Now there isn't any reason to ever tell your customers "no, the only way to undo that is to restore from a backup; that's why we warn you three times before doing it." The nice thing about logging ALL changes is that it lets you undo actions that might only change values in tables instead of just deleting new records.

One of the other potential uses for something like this is to replicate data. Imagine remote sites that need to replicate data to a corporate site nightly (eg. to consolidate accounting info, customer info, orders, etc.) How might you go about doing this with VFP data? If you maintain a transaction log it could be relatively painless. Each remote site logs all transactions for the day. At night this transaction log is sent up to a corporate location and the changes are "rolled forward" into the corporate data. What could be easier (except maybe SQL Server replication)?

Just some ideas I've had about this stuff...