Just curious about building an audit program (a generalized one for the
tool.) In looking over what I did for Forge, it would update the audit
record on every data change. This seems overkill, and am definitely leaning
towards comparing old vs new recs. and updating the audit file at filesave
(or delete) time. Potential problems:

1- How to deal with insertion/deletion of a multivalue line, since clearly I
can't just compare the two mv fields as I'll wind up with a Lot of spurious
changes. I think I can keep track of Ins/Del by some of signal catcher, but
am still befuddled.
2- If user changes a field from A to B, then back to A, is it a change?
(tree falls in forest type question). Forge would record 2 changes;
recording at Filesave time would record none. Can this be a problem in the
post Sarbanes-Oxley world (not that I care, really, just to show I'm up with
the jargon.)
3- Finally, Forge would keep a single discrete stamped record for each
session. Since nowadays very large records are not the problem they used to
be, am leaning towards mv set, say attribute#,old,new,timedate or somesuch.
This is easier for Audit listings (one record per key) but any
disadvantages?

Any thoughts appreciated.

Chandru Murthi

Hi Chandru
I made major changes to our system a couple of years ago for dear old sox so
we have some solid experience of the results.
Two things have become obvious.
Records that have inherent audit trails do not need a separate audit record.
For example a debtors balance control has the transaction detail files to
support it.
Second fast moving data should be separated from static data and probably
treated differently. See example above.
Of course if some clown has embedded the transactions in the master record
one has a monumental problem.
Further comments embedded.

"Chandru Murthi" <cmur_xyz_thi (AT) xyz_seeinggree_xyz_n (DOT) net> wrote

We keep track of program and operator doing the change, time and date and
sequence of change. Yes good old pessimistic locking at point of update.
This was required by the Exxon auditors so doing it at file save is out of
the question. The cost of disk being low we kept the entire previous
record, however we provided a program to just display or print the
variances. Ahah good ideas come unstuck on big records. If we have a
multivalued field or better still a multi sub valued field that grows one
can still have a pretty big record to look at even though just the first or
last value has been inserted so ideally we need to be more specific on
particular files in the analysis program.

Potential problems:
Sydney had good throughput on a margin known down to the fourth decimal of a
dollar, everything balanced, tank dips perfect etc. However the profit was
not there! Change analysis was installed and all became clear. At 2am the
night operator changed the price and all his mates filled up their cars (
they could really afford some long spins up country this way) then he
changed it back again.

I believe that this is the only way that one can easily and accurately track
the sequence of changes.
and I know we do not have the complete answer yet.
Peter McMurray

"Excalibur" <excalibur21 (AT) bigpond (DOT) com> wrote

One clarification..I meant "when you save (file) the record)", did you
think I meant "when you do a filesave?" because otherwise I don't see the
auditor's issue.

I think I have a way around the mv ins/del issue, will have to try it.

Thanks.

Chandru

Hi Chandru
I thought you were going for Filesave time. Sorry about the confusion.
Definitely audit must happen at time of original writing of record. This
does toss in a problem of what happens to one's beautiful sequential audit
record if a Transaction fails but the audit count has already been updated
by another process.

Peter McMurray
"Chandru Murthi" <cmur_xyz_thi (AT) xyz_seeinggree_xyz_n (DOT) net> wrote

Excalibur wrote:
<snip>

I like this approach, but what are you using for your record ID?

Is it the audit_record_ID with a sequential number appened after a
delimiter (i.e. audit_record_ID*sequence_number)?


Curious,
Danny

Personally I'd use sequence*id (or date*id) in case the id itself has
embedded * (quite likely imo)

Chandru
"ddspell-m3" <ddspell (AT) yahoo (DOT) com> wrote

Hi
The audit ID is a number from a master record that is updated atomically.
The true Id along with other data such as file name, operator, time etc is
stored in the control file record. SO the audit file is a deliberate
scramble of records from everywhere intended to muck up anyone fiddling with
it. All reports are generated from the control file.
It has proved useful in tracking who did what and roughly when - does anyone
actually check the system time, I update with one of the atomic clocks but
some users are beyond hope - the sequential id is the real winner.
The sort of thing that I saw many years ago on Reality was order entry clerk
has an order open, hits a problem, calls supervisor who brings up same
debtor in next room, who calls accountant who brings up same debtor. All
make changes and hit commit within 3 seconds, bingo scrambled record. I
believe I have that scenario well beaten with current programming techniques
(reaches for forehead) touch wood. Now I have to cover the clever devil
that changes discount rules, posts invoices, and changes them back again.
When the sole operator is having an affair with one of the drivers and both
meet at the casino, it is amazing that he gets all the large COD
deliveries - actual example from personal experience.
Peter McMurray
"ddspell-m3" <ddspell (AT) yahoo (DOT) com> wrote