Preview the Row You Mean to Change

Suppose the projector’s usual loan period needs to change. Before changing anything, the lending desk should see which stored row belongs to the proposed asset tag and confirm its current values.

Your existing function already provides that preview. Run first shows its familiar checks:

find_item(connection, "TL-100")
(3, 'TL-100', 'Cordless drill', 'tools', 7)
find_item(connection, "NO-404")
None

For the proposed projector change, the caller would use this exact call:

find_item(connection, "EL-300")

It returns:

(5, 'EL-300', 'Projector', 'electronics', 2.5)

That tuple gives a person a useful moment to check the target: ID 5, asset tag EL-300, the expected name and category, and the current period 2.5. If the call returned None, there would be no current row to confirm.

This read-before-change step is a preview. It helps the person or program decide whether the proposed target is the intended one. It does not change the row, hold it in place, or make a later statement safe by itself.

The later changing statement still needs its own precise WHERE condition. Two separate calls do not share a remembered boundary inside SQLite. A correct preview followed by a changing statement with no WHERE could still affect every row. The preview confirms; the changing statement limits its own scope.

You do not need to edit code here. Open catalog_changes.py if you want to trace how find_item binds the tag, then press Run and compare the found and missing cases. The quiz checks the boundary you will rely on when you write the change itself.

Keeping these jobs separate is a useful safety habit: first confirm what you mean to change, then make the changing statement identify that same target for itself.