>>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.

That is an important detail I overlooked at first. It turned out, DBA Admins would run update statements to correct/change data based on specs and those changes were not in their audit reports. So it raised questions why some values existed without corresponding audit. So Triggers would have solved this problem for sure.
Disadvantage is that if your application supports different backends, you certainly have more work at hand.