Check How Many Rows Changed

The before-and-after checks prove that your change functions work, but their callers still receive None. A caller needs a small piece of immediate evidence: did this statement affect one row, or did a unique tag match nothing?

connection.execute(...) returns a cursor. For an INSERT, UPDATE, or DELETE, that cursor’s rowcount reports how many rows that statement affected. Read it immediately from the cursor returned by the changing statement.

Open catalog_changes.py. In add_item, replace the bare call with these two lines:

cursor = connection.execute(statement, item)
return cursor.rowcount

Make the same change in change_loan_days and remove_item, keeping each function’s existing statement and parameter tuple exactly as they are:

cursor = connection.execute(statement, (loan_days, asset_tag))
return cursor.rowcount

cursor = connection.execute(statement, (asset_tag,))
return cursor.rowcount

Do not change find_item; it still returns one tuple or None through .fetchone().

Here is the evidence each changing function should hand back:

Use the cursor from that exact call. If you execute another statement first and inspect a different cursor, the number no longer answers the caller’s question. Keeping cursor = connection.execute(...) and return cursor.rowcount together makes the relationship easy to follow.

Press Run. The calls now report these values alongside the same before-and-after rows:

add_item(connection, (7, "KT-700", "Repair kit", "tools", 5))
1
change_loan_days(connection, "EL-300", 8)
1
change_loan_days(connection, "NO-404", 8)
0
remove_item(connection, "EL-400")
1
remove_item(connection, "NO-404")
0

The insert affects one new row. A matched unique tag lets an update or delete affect one row; a missing tag affects zero. Because asset_tag is unique, these guided functions should never report a number above one when their WHERE condition is correct.

An update can report 1 even when you set the row to its existing value. For example, setting an eight-day item to 8 still matches one row. The count tells you that the statement affected that row, not that the old and new values differ.

rowcount is evidence about the statement that just ran. It does not say that the change has been made durable beyond this open connection, and it is not a catalog-wide total. Keep the cursor from the changing call and return its value before running another statement through that cursor.

Submit checks the returned integers and the resulting catalog together. A hard-coded 1 cannot explain a missing tag, and a correct-looking count cannot make up for changing the wrong rows. Preserve the safe SQL and add only the immediate return.

Your functions now tell their caller what happened in one useful number while the existing row checks still prove exactly what changed.