Re: Log file of file changes

If the file is journaled then just look at the journal receivers.  That is about your only choice.  FWIW - I disagree with your statement 'but that's not really what journaling isfor'......

A quick google search revealed the following -  The primary function of journaling is to store record level database changes and allow those changes to be "rolled back" or undone, if needed. When a file is journaled, any changes at the record level are recorded to the journal first and are then applied to the database record. This is not to say that journaling will always be able to undo any changes that you've done to a file, but it does provide reasonably good protection and a good audit trail.


Warmest Regards,

Richard Reeve



On Wednesday, October 30, 2013 3:44 PM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx> wrote:

All,

We had an issue recently about how a couple of prices got changed.  The
salesrep (who has _some_ control over pricing) says he didn't do it, and no
one in the office remembers doing it.  In fact, it was the sales rep who
brought it up wanting to know what the %#@* is going on?  :)  By looking at
month end backups, I know it happened sometime in August.  Nothing like
bringing it to our attention on a timely basis, right?

Anyway, in discussing it, the buying VP suggested a log file of changes.  I
think it's a great idea and it seems to me to be an ideal use for a
trigger.  Whenever a record is added/updated/deleted, just have the trigger
write the record to this log file.  It can have the same record layout as
the file in question, plus add a few fields such as user and timestamp.
Seem reasonable?  I've never written a trigger before but I can figure it
out.

The file is currently journaled, but that's not really what journaling is
for, IMO.

Thanks for any ideas.