>>But don't you have a (ahem) business rule for deleting records? Could you not put the timestamp in there once the record has been successfully deleted?
>
>Yeah, I do. But the business rules are implemented in the applications that specifically manage the table in question. There are several 'power users' here who occasionally 'clean up' the data in VFP itself. And there are several RI type routines that also have the power to delete records. I just wanted to be able to put the logic in one place as opposed to several.
>
>The reason I need this, is to help in a fairly elaborate synchronization process that happens between local data and the same data on a remote web server. We have robots in place that keep the data synchronized by checking timestamps and sending 'patch' tables to the remote site via FTP, where they are processed by a sentry program that updates the remote copies of the tables. This all works very beautifully except for this little deleted records issue where the sentry program does not recognize that the record's delete status has changes because its timestamp has not been updated.
>
>
>>And...lastly, why am I asking you this when I'm sure you've thought of it and more already??? :-)
>
>Aww, everybody needs to be asked the most simple things sometimes, just to make sure they haven't been walking around with their head up their a$%. Thanks again.
Erik,
WorkLog in File Section already done that for you!
It handle all possible cases editing the table!
- Append Blank, then fill in and Update
- Delete Record
- Recall Record (also make the delete mark switch but trigger Insert Trigger!)
- Insert-SQL
- Update Old Record
The Log Table also carry the Username, Machine, Datetime(Action), Table, key,
fieldname... etc.
Surely can handle the case! What sure take care is the log file will enlarge very fast, you need to zap it every week!
^_~ Best Wish!
The weak wait for chance, The strong bid for chance,
The clever notch up chance, but The merciful give you chance.