A SQL change is invisible to the chosen trigger query
A fictional scenario uses a SQL-query change trigger whose query returns only the total row count. The supplied external table changes values inside existing rows while preserving the number of rows. A colleague expects the scenario to detect every such edit automatically because it is described as a change trigger. Another checks the actual observed query result and the intended freshness requirement. This written exercise runs no query or scenario and changes no trigger. It asks the learner to separate source-table changes from changes visible to the chosen observation, and to explain why a suitable monitored value and controlled validation are needed before claiming complete detection coverage.
1. Why might the trigger not observe this change?
Read the worked answer
The selected count remains unchanged, so that query’s result does not reflect the supplied edits. A change in the table is not automatically a change in every possible query result.
2. What should an authorized design review establish?
Read the worked answer
Define which changes matter and choose a supported observation that captures them appropriately. Test representative edits and the actual trigger/build/reporting behavior without assuming universal detection.