1Z0-047 · Question #208
Evaluate the following SELECT statement and view the Exhibit to examine its output: SELECT constraint_name, constraint_type, search_condition, r_constraint_name, delete_rule, status FROM…
The correct answer is A. In the second column, indicates a check constraint. D. The column DELETE_RULE decides the state of the related rows in the child table when the corresponding. See the full explanation below for the reasoning.
Question
Evaluate the following SELECT statement and view the Exhibit to examine its output:
SELECT constraint_name, constraint_type, search_condition, r_constraint_name, delete_rule, status FROM user_constraints WHERE table_name = ORDERS Which two statements are true about the output? (Choose two.)
Exhibit
Options
- AIn the second column, indicates a check constraint.
- BThe STATUS column indicates whether the table is currently in use.
- CThe R_CONSTRAINT_NAME column gives the alternative name for the constraint.
- DThe column DELETE_RULE decides the state of the related rows in the child table when the corresponding
How the community answered
(42 responses)- A76% (32)
- B17% (7)
- C7% (3)
Community Discussion
6
Hiroshi T.Feb 16, 2026The correct answers are A and D. Per Oracle's documentation on the USER_CONSTRAINTS data dictionary view, the CONSTRAINT_TYPE column stores a single-character code where C denotes a check constraint, making option A accurate for what the second column indicates. The DELETE_RULE column, as defined by Oracle, specifies the referential action applied to child table rows when a parent row is deleted, which is exactly what option D describes. Option B is wrong because STATUS reflects whether the constraint is ENABLED or DISABLED, not table usage. Option C is wrong because R_CONSTRAINT_NAME identifies the referenced primary or unique key constraint in the parent table, not an alternative name.
Orla P.Feb 28, 2026C trips people up every time because "alternative name" sounds plausible, but R_CONSTRAINT_NAME is the name of the primary or unique key on the parent table that the foreign key points to, which is nothing like an alias. Go with A and D, since C in the CONSTRAINT_TYPE column does flag a check constraint and DELETE_RULE is exactly what controls what happens to child rows when you delete from the parent.
Mei-Ling H.Mar 1, 2026R_CONSTRAINT_NAME being the parent key name rather than an alias is the key insight most people miss, though it is worth noting that CHECK constraints appear in USER_CONSTRAINTS but CONSTRAINT_TYPE = 'C' also covers NOT NULL constraints, so if a question asks specifically about user-defined check constraints that detail can flip which answer survives elimination.
Bao N.Mar 8, 2026So C_TYPE = 'C' for check and 'R' for FK, but what exactly triggers the DELETE_RULE cascade here?
Mei-Ling H.Feb 9, 2026I almost picked C because "R_CONSTRAINT_NAME" sounds like it could mean an alternate or renamed constraint, but then I remembered the R stands for referenced, so it only has a value when the constraint is a foreign key pointing to a parent table's primary or unique key. Once I locked in D for DELETE_RULE controlling CASCADE or SET NULL behavior on child rows, and confirmed A because constraint_type value "C" specifically marks a check constraint, everything lined up.
Bao N.Feb 12, 2026The R_CONSTRAINT_NAME trap gets a lot of people because they overthink the naming, but your delete rule point is worth drilling too, since test writers love to mix up DELETE_RULE with SEARCH_CONDITION and both columns live right there in ALL_CONSTRAINTS making it easy to cross-wire them under pressure.