Exam 1z0-149 topic 1 question 22 discussion

I vote for CEF. I don't agree with D.

WT*. A is incorrect. Correct is CEF A. Implicit cursor returns only one record. This is incorrect. Implicit cursors handle queries that may return one or more records. However, they are typically used for SQL statements that return a single result, such as SELECT INTO. But, they are not limited to only one record.

F- DDL triggers can also be fired when specific DDL statements like GRANT, REVOKE, or other object-level privileges are applied to a user. A A. They cannot include the WHEN clause. DDL triggers can include the WHEN clause, which can be used to specify conditions under which the trigger should fire.

To me 4 or 5 are correct : ) A. They cannot include the WHEN clause. -False Unless it's a part of Exception block B. They must be created in an enabled state. - False C. They can be fired when a table is truncated. - True CREATE OR REPLACE TRIGGER truncate_trigger_after AFTER TRUNCATE ON USER1.SCHEMA BEGIN RAISE_APPLICATION_ERROR ( num => -20000, msg => 'Truncated'); END; / D. They fire only when a DDL statement is executed by the owner of the trigger. - True per documentation E. They can be fired either before or after a DDL statement executes. - True see point C F. They can be fired when a privilege is granted to a user. - True GRANT is listed among DDL Events of System Trigger CREATE OR REPLACE TRIGGER grant_trigger_after AFTER GRANT ON USER1.SCHEMA BEGIN RAISE_APPLICATION_ERROR ( num => -20000, msg => 'Granted'); END; / G. They must be created in a disabled state. - False

A. They cannot include the WHEN clause. DDL triggers cannot include the WHEN clause, as this clause is used for row-level triggers to define a condition that must be met before the trigger fires. C. They can be fired when a table is truncated. DDL triggers can be fired by a TRUNCATE statement, as this is a Data Definition Language (DDL) operation. E. They can be fired either before or after a DDL statement executes. DDL triggers can be created to fire either before or after a DDL statement is executed. This allows for various actions to be taken, such as logging or validating changes, depending on the specific DDL operation.