|
|
Posted by --CELKO-- on 05/12/07 23:14
>> My goodness! Maybe I should explain a little... this is a configuration database for a large industrial process. The database itself is backed up every night, so the machinery / process can always be restored to a known working state. <<
Okay, this is not SOX or one of those things,and you do not care that
you can be 24 hours out of date on the machinery configurations.
But what about loss of the production data. "How many widgets did we
make today?" "I don't know; the DB was blown up by Lichtenstein
terrorists and all we have left is yesterday's stats." Is that on
another machine with a proper back up and audit trail?
>> The purpose of my audit table, which is indeed stored in the same database, is so that when the process begins behaving differently, folks can go back and see that, during a previous shift, an operator tweaked (or fat fingered) an operational value. <<
LOL! I have not heard "fat fingers" in years! We also used "OS
problem", but OS was "operator stupidity" and not "operating system".
On a more serious note, have you looked at Sequential Analysis and Ev
Op techniques to go against that data? SAS or SPSS might be able to
give you a lot of good info on the process.
>> I suppose the audit table could indeed provide a "reason for termination" someday, but hopefully not mine... <<
LOL!
Navigation:
[Reply to this message]
|