Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

dynamically passing %rowtype

Status
Not open for further replies.

robin316

Programmer
May 31, 2001
3
US
I've built an update row trigger on several tables. The purpose is to capture the old and new values in variables then passing these values to a package containing MANY functions/procedures that validate the data. Each table is structured differently. I've got about 183 tables that need to have this trigger applied to it.

Anyway, the workaround I've found for the first few tables is to overload the procedures in the package and pass in the literal table_name%rowtype (ex. emp%rowtype). This is at best a cumbersome solution because of the number of tables that will eventually be passed.

I've tried the following:

1) dynamically building the %rowtype variable then passing that variable (on compile I get an error saying table_name must be a table)
2) creating a global temporary table in a separate procedure using pragma autonomous transaction (when I run the update I get an ORA-03031 error because the user has insufficient priveliges. We want to assign priveliges by roles not by individuals, so this option doesn't work for us.)
3) create a cursor by inserting the new/old values into the cursor. (seems that we have to do a select statement to create the cursor then fetch records from the cursor into a variable. We really just want the table structure, not the data. Then we want to insert the values from the :eek:ld & :new values).
4) Our DBA doesn't like varrays, nested tables, or object types so that doesn't seem to be an option.

I know these triggers must be done all of the time, but I can't figure out how to do it.


tia, robin




 
Don't know if this will help you or not, but on several systems I work on, I had what I think is a similar problem. I wanted to do some custom auditing, to record in a log changes made to data in each table and some information about who made the change, when, etc.

What I have done that works well for me is to write a SQL*PLUS script that generates the triggers. It uses information in the USER_TABLES, USER_TAB_COLUMNS and other system views to build the triggers. Sometimes, when I want some variability, I put some metadata in the table and/or column comment fields. For instance, if I only want to audit certain tables, I can put a comment of <NO AUDIT> on any table I don't want to audit. My script can query that comment (via the USER_TAB_COMMENTS view) and skip any tables that have that comment. I also have a package of routines that deal with the actual auditing and the generated audit triggers call routines in this package.

Once the script is written, it is run any time new tables are added or the structure of existing tables are modified.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top