Triggers vs Journals -- MIDRANGE-L

Tom,

I agree that Journals are certainly more tamper-proof than a Physical File and when we attempted to do what Reeve is doing, our choice was to extract the info from the Journal Receivers. (But in our case the Journaling is already implemented for our HA application.)

But if you're building an Audit Application, the Receivers themselves just can't be the permanent repository for the Transaction History. They just get too Big. At least when, as in our situation, practically every file on the system is being Journaled to a single Journal. And that's commonplace for our particular HA application. We keep only a few days worth of Receivers on our system and they account for a significant amount of Disk Space.

And there's also no way to filter out any "False Positives" on updates.... Transactions where nothing changed or only a Timestamp/User/Job field(s) were actually updated. This can lead to so much useless info that it makes it almost impossible to find the meaningful stuff.

I guess if you Saved your Receiver Backups for years and years, with great effort you could always track down what happened to the Data. But if you want your Audit Application to be Online, at some point in time, I think you're faced with the fact that this info has to go to a Data base File. And the Data should be secured in a way that satisfies the Auditors.

We currently run our reports on a Daily, Weekly and MTD basis so that our Users can be pro-active in finding any Fat-Fingered problems. We couldn't do that if the info wasn't in a Database File. As for whether or not the Auditors will actually trust our Audit Files..... They're here this week, so we shoud know real soon. Wish us Luck.

Mike

  6. RE: Fastest way to get a unique identifier/tracking column
     changes (Reeve)
I don't believe the results will be different depending upon which approach, trigger or journal receiver, you use. It's about implementation, stability, and performance.


I'd suspect this to be more or less true depending on the purpose. If
it's simply a form of historical tracking that perhaps supports
drill-down or other application functions, then a trigger writing to a
file is perfectly reasonable. But if this is an actual audit function
mandated by auditing requirements or regulations, then journaling is the
only reasonable choice.

Journal entries are system-enforced and reasonably secure from
tampering. Logging to a physical file provides no significantly secure
audit capability at all. Anybody with authority can generate rows,
update or delete rows, and put any desired info into or take undesired
info out of a physical file. But manipulating journal entries is
significantly more difficult.

There's no way to demonstrate that the rows in a log file were the
result of actual operations -- unless, of course, you also journal
activity against the log file which brings you right back to journaling
and only demonstrates activity against the log file not the original
tables. IMO, as audit evidence, a log file is effectively worthless.
Opinion? Yes, certainly. But I haven't seen a good way around it.

Tom Liotta

_________________________________________________________________ MSN 9 Dial-up Internet Access helps fight spam and pop-ups ? now 2 months FREE! http://join.msn.click-url.com/go/onm00200361ave/direct/01/