Which kind of backs up my original assertion in the forum thread, which was that when working with a collection and using statement level trigger work, a single INSERT/UPDATE/DELETE using TABLE (CAST ( )) should be preferable to FORALL.

The constant requirement to re-review the basics, previously known “facts”, knowledge gaps and also your assumptions is one of the things which makes working with Oracle so interesting.

The INSERT…VALUES doesn’t really depend on its sequence or table state. In theory they can be run in any order (ignoring any triggers or exceptions from unique constraints, and assuming absolute values not scalar subqueries) and achieve the same thing. They could practically be re-written as a single statement of the form INSERT…SELECT .. FROM TABLE(collection_variable)
11gR2 even allow for direct path inserts with FORALLhttp://www.oracle-base.com/articles/11g/AppendValuesHint_11gR2.php

UPDATEs and DELETEs are different. The order in which they are executed might matter (eg update 1 adds 5 to a column value and update 2 doubles the value).

I came across it first in 9i when optimising code with expensive actions on row triggers. I moved the action to an after statement trigger with the for row triggers populating collections (with the ability to flush to the expensive action when the collection hit a certain size). And I explained to another developer that for the trigger stuff to have the best effect, it had to be an INSERT…SELECT becauses a FORALL INSERT would trigger the after statement for each row. I was wrong.