SE 7.25.UC5 table audit question.
Posted in 2013
Topics: Stored Procedures & SPL, Security, Permissions & Auditing
I created an audit for a table. I now want to create an ISQL Perform screen which displays all the columns of the rows in the audit table so I can see at what datetime users inserted, updated or deleted rows, including each columns contents, so I could see the history of updated columns. It would also be nice to know at what datetime and which rows the users viewed. Is there an easier way, other than the ole trick of converting the .aud to a .dat, then creating an index? I would think that besides an audit's main puprose is for recovering a table, an admin could also easily inspect the audit data for security and journaling purposes, as the term "audit" implies this in the realworld.
The SE (really C-ISAM) audit trails date back to about 1982, when the world was a different place. You don't get information about rows read in an SE audit trail. There isn't an easier way than creating a table and an index that I know of. The information is made available; there are no tools that I know of for analyzing an SE/C-ISAM audit trail. I'm not sure whether there's any information about rollbacks; what you see in the log file might not be wholly the same as what you find in the data file. However, I've not checked whether there are compensating audit records to record the rollback (it is quite conceivable that there are such records). On Tue, Aug 20, 2013 at 3:47 PM, FRANCISCO USER/DEVELOPER < frankcomputer@ymail.com> wrote: > I created an audit for a table. I now want to create an ISQL Perform screen > which displays all the columns of the rows in the audit table so I can see > at > what datetime users inserted, updated or deleted rows, including each > columns > contents, so I could see the history of updated columns. It would also be > nice > to know at what datetime and which rows the users viewed. Is there an > easier > way, other than the ole trick of converting the .aud to a .dat, then > creating > an index? I would think that besides an audit's main puprose is for > recovering > a table, an admin could also easily inspect the audit data for security and > journaling purposes, as the term "audit" implies this in the realworld. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." --047d7b66fc1749750904e468f3b2