>>Just for the record, I don't use Triggers to log changes. And as far as viewing the log file - via a VFP report - this feature can be set on/off by the user of the application.
>
>Obviously, different opinions and different approaches out there.
>
>My reason for usually advocating triggers - they are going to fire regardless of what process changed the row. It could be a DBA manually changing some rows, or an overnight ETL process to load data from a legacy system, etc. Many different scenarios where a table could be updated, but the trigger will always fire.

I am sure that triggers can do the job I am doing with my audit trail class. I simply don't know triggers that well and as a result not trust them. It is me, not triggers.
But the class that save the change in the audit file works very well. It saves, who made the change, the time, record number, type of change ("E/D/A"). And it stores the actual change is a specific format that allows me to get the information in the report. Here is an example, of how my class stores the information in one of the fields of the audit table:

cChanges = "<Fld><Name>MyField1</Name><OV>ABC</OV><NV>XZY</NV></Fld><Fld>
<Name>MyField2</Name><OV>123</OV><NV>FHFH</NV></Fld>"

As far as what you said about DBA manually changing some rows. I do not allow DBA (verbally, of course) to make ANY changes to my DB. All changes have to be done from the application.

Thank you for your message.