A cascading trigger results when a triggering statement fires a trigger, which in turn fires another trigger. The situation is such that the table being updated by the first trigger also has a trigger associated with it and becomes the new subject table. Then the second trigger updates a table that has a trigger associated with it. So, each triggered statement in turn becomes a triggering statement.
The only thing a trigger cannot do is to change the subject table on which the trigger is defined. However, a subsequent trigger may come back and update the original subject table. Caution should be exercised here so that the triggers do not cascade indefinitely. This constitutes an infinite loop and will cascade until they run out of either Permanent or Transient Journal space, or the transaction is aborted.
Cascading Trigger example:
In this cascade example, there are three tables: CasTbl_1, CasTbl_2 and CasTbl_3. Each table is defined with two columns called: Col1 and Col2. At the beginning of the process, all three tables are empty.
All three tables use basically the same CREATE TABLE to build the initial definitions; only the names have been changed.
Now the triggers are defined to monitor the rows in the tables called CasTlb_1 and CasTbl_2:
Now that the tables and triggers have been defined, the trigger statement can be issued:
INSERT INTO CasTbl_1 values (1, 4);
The next SELECT operations are to verify that the triggers worked:SEL * FROM CasTbl_1; 1 Row Returned
The above output is from the original insert into the first table.
Look what happens when a SELECT is performed on each of the other two tables:SEL * FROM CasTbl_2; 1 Row Returned SEL * FROM CasTbl_3: 1 Row Returned
The first trigger inserted a row into CasTbl_2 as a result of the original insert into CasTbl_1. Then, the second trigger inserted a row into CasTbl_3 because of the inserted row into CasTbl_2. All of this happened as a result of the original INSERT; they cascaded from the original row.
Remember the one thing to avoid when using cascading triggers. Do not create a trigger on either CasTbl_2 or CasTbl_3 that will insert a row into CasTbl_1. This causes an indefinite loop of the INSERT operations that will continue until aborted.
Teradata Related Interview Questions
|Microstrategy Interview Questions||Informatica Interview Questions|
|MySQL Interview Questions||Oracle 11g Interview Questions|
|Hadoop Interview Questions||TeraData DBA Interview Questions|
|MYSQL DBA Interview Questions||Database Administration Interview Questions|
|DB2 SQL Programming Interview Questions||Hadoop Administration Interview Questions|
|Java Hadoop Developer Interview Questions||Informatica MDM Interview Questions|
|Informatica Admin Interview Questions||Hadoop Testing Interview Questions|
Teradata Related Practice Tests
|Microstrategy Practice Tests||Informatica Practice Tests|
|MySQL Practice Tests||Oracle 11g Practice Tests|
|Hadoop Practice Tests||TeraData DBA Practice Tests|
|MYSQL DBA Practice Tests||Database Administration Practice Tests|
|DB2 SQL Programming Practice Tests||Hadoop Administration Practice Tests|
Teradata Parallel Architecture
Fundamental Sql Using Select
On-line Help And Show Commands
Date And Time Processing
Character String Processing
Reporting Totals And Subtotals
Data Definition Language
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.