Housing caseworkers call a procedure that advances case status and must receive the new queue_number back to the client app. Which design meets that need?
Select an answer to reveal the explanation.
Short Explanation
Output parameters are the sticky note the procedure hands back with the new queue number after it flips the case status. Constraints keep data honest; they are not a return path to the app.
Full Explanation
Housing caseworkers who call a procedure to advance case status and must receive the new queue_number back need a bidirectional contract: inputs for the case key and target status, a write that updates the case, and an explicit channel that returns the assigned queue number to the client app. A stored procedure with an output parameter (or a result set designed for that purpose) meets that need—the procedure updates status, assigns or reads queue_number, and sets the output so the caseworker UI can route the file without a second round-trip guess.
CHECK constraints validate column values; they do not emit queue_number as a result set or talk to the application. UNIQUE constraints enforce uniqueness of queue_number; they are not an output channel to the app. An external table over blob storage may expose files for analytics, but it does not participate in case-status updates or return queue numbers to caseworkers during the status change call.
Exam caveat: distinguish declarative constraints (data integrity) from procedural interfaces (business workflow plus return values). Output parameters, RETURN codes, and result sets are the supported ways to hand values back from procedures—not constraints. Operational check: execute the procedure from a test harness declaring an output variable, advance a known case, and assert that the output queue_number matches the value persisted on the case row.