Hi CK,
You are right in that I am using Front-End application which holds logged user details.I Could not understand the "Updateable View" concept.Could you explain it for me to implement audit-log.
Thanks with Anticipation,
Preethi
options 1:
1. create an RecordStat, UpdatedBy, UpdatedOn columns on your table.
2. get all the value of the fields of the table you are updating.
3. instead of issuing an UPDATE statement on the updated field, just update RECORDSTAT = 'I' (or 0 or whatever value you like to signify that the status of the record is inactive). this can also be done if the user delete the record from the GUI
4. on your update statement, build it in such a way that it will be a combination of values from your variable and from your GUI. the value from your variable are those you gather from #2 (above). the value from your GUI are those that your user updated.however for Recordstat = 'A', UpdatedBy = ValueFromYourGUIThatHoldsUserLoggedInfo, UpdatedOn = systemdate(). you will now have an almost duplicate record. with the exception of the fields that were updated and the 3 new fields.
5. In all your query, you have to be conscious that only active records has to be chosen. this means you have to add WHERE RECORDSTAT = 'A' on all your query.
challenge: a user can go to sql analyzer and mess up your table and no audit will be done
option 2:
1. create an RecordStat, UpdatedBy, UpdatedOn columns on your table.
2. create an update trigger on your table
2.a. when update trigger fires, insert the entire deleted table on your table with the exception of RecordStat values of these fields should be RecordStat = 'I'.
3. you should have an almost identical record with the exception of the three fields.
4. In all your query, you have to be conscious that only active records has to be chosen. this means you have to add WHERE RECORDSTAT = 'A' on all your query.
challenge: lot of programming work; disk space (but storage are cheap)
option 3:
1. create an update and delete trigger on your table.
2. when update or delete trigger fires, insert the deleted table into a "dump" table where you dump all updates and deletes. before inserting, make sure to capture the UpdatedBy and UpdatedOn values.
3. this way, you don't change any other queries, you keep your table as is, and you have the audit somewhere else. you can use the audit table for analysis
challenge: lot of programming work; disk space (but storage are cheap); your table is not really complete and has to be split into two
it would all depend on how big your table is. this could all be fine if you have small size. for bigger (read: million-s), try option 3. try all and check for performance.
views triggers
hope that make sense :)
-- ck