was wondering if anyone had any insight on creating an audit trail process in VB6?
I have an application that gets populated with existing data with the use of 3 or 4 classes. The user can then modify any data they wish on this application. Then the data is saved into tables used for a queue. Basically exact copies of the tables the data came from. My problem is I need to create an audit trail.
What is the best practice for this? Compare every control (text box, radio, check box) on the application which is around 100? Or can I utilize the text_changed event of the text boxes? Really have no idea where to start on this one.
Oh and to make it fun, using a Pervasive DB v9.
Thanks for any help.
Cheers
This should always be done inside the DB.
Something like this (cribbed in part from post to the pervasive forum, I haven't actually used Pervasive):
create trigger insTrig
before insert on table1
referencing new as new_rec
for each row
insert into table2 values (new_rec.co1,new_rec.col2,new_rec.col3,...)#
create trigger delTrig
before delete on table1
referencing old as new_rec
for each row
insert into table2 values (new_rec.co1,new_rec.col2,new_rec.col3,...)#
create trigger updTrig
after update on table1
referencing new as new_rec
for each row
insert into table2 values (new_rec.co1,new_rec.col2,new_rec.col3,...)#
Related
So, i am a begginer on ORACLE and realy would apreciate your help.
I have 3 tables, EMPLOEES, PERSONAL_DATA and RECORDS. I want to create an UPDATE TRIGGER that when fires takes the old values of EMPLOOES finds the personal data of that updating emplooe on the PERSONAL_DATA table with the OLD id and insert all of that data( the OLD of EMPLOOES and the one fetched from PERSONAL_DATA) into the RECORDS table. I been triying to use the SELECT sentence to fetch information from the table PERSONAL_DATA, but the compiler throws me an error.
Can anyone suggest a good event pattern design or framework for changes in table in oracle.
Changes are not just the based on the column value change,but also the business driven logic .All the logging should be driven by some event setup.
At the end we track the changes and drive the business logic based on the changes .
I might be talking too high level,sorry for that :)
Assume TableA needs to be tracked for ColumnA.
Create AUDIT_TRAIL Table with columns TABLENAME, COLUMNNAME, OLDVALUE,NEWVALUE, DATEANDTIME, PK_SEQ
Create a Trigger to poll TableA for any change in ColumnA, and insert them into AUDIT_TRAIL (PK_SEQ should be a Oracle Sequence Number, DATEANDTIME should be from sysdate)
Something like this for trigger
CREATE OR REPLACE TRIGGER trg_table_audit
before insert or update or delete on tableA REFERENCING NEW AS NEW OLD AS OLD
for each row
begin
if inserting or deleting then
insert into audittrail (....)
Reading the fine manual: Using Triggers to Write Audit Data to a Separate Table:
You can use triggers to supplement the built-in auditing features of Oracle Database. The trigger that you create records user actions to a separate database table. When an activity fires the trigger, the trigger records the action in this table. Triggers are useful when you want to record customized information such as before-and-after changes to a table.
Reading even more the fine manual: PL/SQL Triggers:
A trigger is like a stored procedure that Oracle Database invokes automatically whenever a specified event occurs.
On top of that you can build a setup engine that turns triggers on and off. The "business logic" can later read the data recorded by the triggers.
I assume you're not interested in auditing. For the details see e.g. Verifying Security Access with Auditing.
How about you start with using TRIGGERS? And then from there, you could call procedures/functions from a package body for tracking the changes on the table/s.
I have come into a bump at my current company where they have an account and a member. For some reason or another both are stored in separate tables.
Right now a member and an account can be registered. That's fine, except the users of both member and an account can have the same username. This is of course as you all know just wrong. Especially since they use the username to login to the same system except with different functionality levels.
Right now we are doing a check at the application level, and we're just wondering if it's possible to get the database to enforce two columns to be unique, say like a union of the two tables.
Can't set them up as primary or foreign key at the moment but that's for future anyway. Right now looking for a quick fix. In the future I will probably merge databases and get all members added on as new rows in the account table and add a boolean for IsMember.
In general, I agree with the consensus opinion that it's better to fix the design than to kluge a fix using triggers. However, a properly implemented trigger-based solution is still probably better than your current situation.
If you're going to use triggers, the right way to do it is to:
Create a new table that will contain nothing but usernames, with a primary key enforcing uniqueness (this may, in fact, be a good candidate for an indes-organized table).
Create before-insert triggers on both existing tables that add the new username to the new table. If the new username already exists, an error will be thrown, preventing the insert of both rows. Of course, the application will need to be able to handle this error gracefully (presumably it already can, for scenarios in which the new username already exists in the table it's being added to).
The wrong way to do this would be to make the trigger select from the other table, in order to verify uniqueness.
You can add a trigger that enforces your requirement.
The recommended triggers tend to be really brittle with concurrent transaction.
What you can do (AFAIK) is to create a materialized view containing the union of the column in question and put a unique constraint on that column.
Make sure you do some performance tests though.
As you use a soft delete pattern.
A trigger could be used (on each table) as a temporary measure.
By inserting a disabled record in the the other table, you will get a failure if the other record already exists
Remember this will not enforce the rule on existing data, only records that are inserted will be checked
Something like this:
-- Insert into the accounts table too
CREATE OR REPLACE TRIGGER tr_member_chk
BEFORE INSERT ON members
FOR EACH ROW
BEGIN
INSERT INTO account (name, id, etc, isenabled) VALUES(:new.name, :new.id, :new.etc, 0);
END;
-- Insert into the members table too
CREATE OR REPLACE TRIGGER tr_account_chk
BEFORE INSERT ON accounts
FOR EACH ROW
BEGIN
INSERT INTO members (name, id, etc,isenabled) VALUES(:new.name, :new.id, :new.etc,0);
END;
I have a database schema which is identical in files 1.sqlitedb through n.sqlitedb. I use a view to 'merge' all of the databases. My question is: when i insert into the view, into which database does the data get inserted into? Is there any way to control which gets the data? The way that i need to split the data depends on the data itself. Essentially, i use the first letter of a field to determine the file that it gets inserted into. Any help would be appreciated. Thanks!
Writing to views is NOT supported for SQLite like it is with other dbs.
http://www.sqlite.org/omitted.html
In order to achieve similar functionality, one must create triggers to do the necessary work.
We need to implement instead of trigger on the view (VIEW_NAME) . So when insert/update happens view . we can insert update underlying object (TABLE_NAME) in the trigger body.
CREATE TRIGGER trigger_name instead of INSERT on VIEW_NAME
BEGIN
insert into TABLE_NAME ( col1 ,col2 ) values ( :new.col1, :new.col2);
END;
I'm not sure I understand your question, but have you looked into using the ATTACH DATABASE command? It allows you connect separate database files to a single database. You can control INSERTs into a specific database by prefixing the database name (INSERT INTO db1.Table).
http://www.sqlite.org/lang_attach.html
I'm wondering if its possible to create a view that automatically checks if there is a new monthly created table and if there is include that one?
We have a new table created each month and each one ends with the number of the month, like
table for January: table_1
table for February: table_2
etc...
Is it possible to create a view that takes data from all those tables and also finds when there is a new one created?
No, a view's definition is static. You would have to replace the view each month with a new copy that included the new table; you could write a dynamic PL/SQL program to do this. Or you could create all the empty tables now and include them all in the view definition; if necessary you could postpone granting any INSERT access to the future tables until they become "live".
But really, this model is flawed - see Michael Pakhantsov's answer for a better alternative - or just have one simple table with a MONTH column.
Will be possible if you instead of creating new table each month will create new partition for existing table.
UPDATE:
If you have oracle SE without partitioning option you can create two tables: LiveTable and ArchiveTable. Then each month you need move rows from Live to ArchiveTable and clean live table. In this case you need create view just from two tables.
Another option is to create the tables in another schema with grants to the relevant user and create public synonyms to them.
As the monthly tables get created in the local schema, they'll "out-precedence" the public synonyms and the view will pick them up. It will still get invalidated and need recompiling, but the actual view text should need changing, which may be simpler from a code-control point of view.
You can write a procedure or function that looks at USER_TABLES or ALL_TABLES to determine if a table exists, generate dynamic sql, and return a ref cursor with the data. The same can be done with a pipelined function.