1D0-541 · Question #123
Which of the following best describes the ON DELETE NO ACTION referential integrity constraint?
The correct answer is C. If any child key references a parent key, the record containing the parent key cannot be. See the full explanation below for the reasoning.
Question
Which of the following best describes the ON DELETE NO ACTION referential integrity constraint?
Options
- AIf a parent key is deleted, any child keys referenced by the parent key are automatically
- BIf a parent key is deleted, no test is made for referential integrity.
- CIf any child key references a parent key, the record containing the parent key cannot be
- DIf a parent key is deleted, all child keys are automatically set to a specified value.
How the community answered
(37 responses)- A3% (1)
- B8% (3)
- C84% (31)
- D5% (2)
Community Discussion
9The answer is C. Think of it like trying to delete a department from a company database while employees still list that department as their home, the system just flat-out refuses the delete until every last child record is reassigned or removed first. ON DELETE NO ACTION is the database playing bouncer, not babysitter, it does not move or change child keys for you, it simply blocks the parent deletion if any child still points to it.
C is the one, and once you see the logic it sticks forever: NO ACTION means the database refuses the delete entirely if any child row still points at that parent, so the constraint protects the relationship by stopping the operation cold rather than cascading or nulling anything out.
Worth flagging for exam purposes that the SQL standard technically separates NO ACTION from RESTRICT by timing, NO ACTION being deferred to end of transaction while RESTRICT fires immediately, but most engines collapse that difference and most cert questions will not test it unless the stem specifically mentions deferred constraints.
Going with A on this one, and here is my reasoning. The phrase "NO ACTION" sounds passive at first, but I read it as the database taking automatic compensatory action on the child records the moment the parent is deleted, which is exactly what A describes. Think of it this way: the constraint has to do something when triggered, and "automatically" handling the child keys is the database fulfilling its referential integrity duty without requiring a manual follow-up from the user. Option C sounds more like a RESTRICT behavior to me, where the delete is blocked outright, which feels like a separate constraint type entirely. The wording in A lines up with how I picture the engine resolving the broken reference chain on its own once that parent row disappears.
Hey Prof. Sara, really appreciate the breakdown, but I think NO ACTION actually does the opposite of what A describes, it blocks the delete and throws an error if child records still exist, which is exactly what C says. The automatic cascading behavior you described in A is what CASCADE does, not NO ACTION.
C is right, NO ACTION means delete is blocked if child rows exist.
Correct on the blocking, Luis, but sharpen your language for the exam: NO ACTION defers the constraint check to end of transaction while RESTRICT fires immediately, so within a single transaction that reorders rows first then deletes the parent, those two keywords can produce different outcomes.
C is right. ON DELETE NO ACTION means the database will reject any attempt to delete a parent row that still has dependent child rows referencing it, so the constraint enforcement happens at the end of the statement and raises an error if violations exist.
The end-of-statement timing Orla mentions is exactly where NO ACTION diverges from RESTRICT, and that gap matters even more when you declare the constraint DEFERRABLE INITIALLY DEFERRED, because then enforcement slides all the way to commit time, something RESTRICT can never do.