Transactional control statements in trigger

Question

Hi,
  Transaction Control statement, which cannot be executed within a trigger body??why...explain with reason
its helpful me..

Answer 1

Ishan wrote:
"a way you can actually make it work" .... seriously?
Yes, I was serious. Why? What's wrong with that? Technically speaking, won't it work?
This is not a way to make it work, it's a way to break an application/process
Well !!! All the cases?
Here's  a scenario
I want to audit a table where if any change done by the user has to be tracked in an audit table, irrespective whether the change has now been rolled back in the main table. I want to see what change was done? How would I do it? Going by your logic of breaking application/process, I should never use trigger as  AUTONOMOUS_TRANSACTION. Am I right? How would I achieve it now?
Your auditing/tracing code should be in a separate procedure and that procedure should be autonomous, so that the requirement to write autonomous data for that purpose is kept isolated from the trigger code.  Consider this scenario instead.  You want to write audit/trace information from your triggers, so you make the trigger autonomous and put in your code to write the audit/trace information.  Later on, someone who hasn't a clue comes along and decides they need to do something else in that trigger (well why write a new trigger when one already exists?) and they get it to write some data in relation to the data being created by the trigger.  Now you suddenly have a transactionally unsafe application, where this 'child data' can still be written and committed even if there's a problem in the main transaction.  By isolating auding/tracing away to it's own autonomous procedure, you make it clear that it's only the auditing/tracing that should be autonomous and prevent any problems from occuring inside the trigger itself.
That's more of a way to write bad code that is transactionally unsafe and demonstrates a lack of understanding of database transactional processing or how the rdbms on the server processes commits and could potentially lead to write contention in the writer processes, of which many would be spawned if the number of inserts (in this example) was high.
The above comment is based on the assumption(which, I never stated) that in whatever scenario my code would be implemented, it would ALWAYS break the process. There are scenarios where this code could be required.
Here's a link from Oracle Documentation, that uses an example of creating a trigger with AUTONOMOUS_TRANSACTION. If it is a so bad example which "demonstrates a lack of understanding of database transactional processing", why would Oracle even mention it in their documentation?
http://docs.oracle.com/cd/B19306_01/appdev.102/b14261/sqloperations.htm#BABDHGAB
And the answer is because there is a way to do it and it could actually be required, even though it's rare.
I just showed OP, that it's not allowed directly and if required, it can be done as there is a way to do it. When to do it and what could be the consequences was never the scope of the question.
Yes, and there's ways to jump off cliffs and kill youself, but I wouldn't recommend demonstrating how to do that to people just because it's possible.
Just because it's in the oracle documentation doesn't always mean it's best practice.  A lot of the documentation was written a long time ago and best practices have changed as well as further functionality added, and Oracle has been known to make mistakes in their documentation too.  However in this example, it's using it for auditing purposes, so the idea was almost there, but they still haven't met best practices of keeping the auditing isolated, so their example is not the best.