A developer runs: UPDATE employees SET salary = 75000; What happens?
AOnly employees with NULL salaries are updated, since those are the unset rows
BThe statement fails with an error because a WHERE clause is required for UPDATE
CEvery row in the employees table has its salary set to 75000
DOnly the most recently inserted employee row is updated
Without a WHERE clause, UPDATE applies to every row in the table. SQL does not require a WHERE clause or warn you — it happily updates all rows. This is one of the most dangerous mistakes in SQL and a major reason to write the WHERE clause before the SET clause as a habit.
Question 2 Multiple Choice
Why should INSERT statements always list column names explicitly rather than relying on positional order?
AListing column names is required by the SQL standard; positional inserts are not valid syntax
BPositional inserts are significantly slower because the database must scan the full schema
CIf the table is later altered — columns added, reordered, or removed — positional inserts may silently insert values into the wrong columns
DColumn name lists enable constraint checking; positional inserts bypass NOT NULL validation
Positional inserts assume a specific column order. If the table schema changes — a column added in the middle, or the order revised — the values shift to the wrong columns without any error. Explicit column names make the mapping unambiguous and protect against schema drift. Constraints apply equally regardless, and performance is not materially affected.
Question 3 True / False
A DELETE statement without a WHERE clause will fail with an error, because SQL requires you to specify which rows to delete.
TTrue
FFalse
Answer: False
SQL does not require a WHERE clause on DELETE. A bare DELETE FROM tablename; is perfectly valid syntax and will delete every row in the table, leaving it empty — with no confirmation prompt. This is why wrapping destructive DML in a transaction (so you can ROLLBACK) and always including WHERE clauses are essential practices.
Question 4 True / False
If you attempt to INSERT a row that violates a NOT NULL or FOREIGN KEY constraint, the database will reject the insert rather than storing invalid data.
TTrue
FFalse
Answer: True
Constraints are enforced at the moment of DML execution. An INSERT violating NOT NULL, FOREIGN KEY, UNIQUE, or CHECK is rejected with an error and no row is stored. This is a core benefit of defining constraints at table creation: the database guarantees data integrity automatically, so application code doesn't need to duplicate that validation.
Question 5 Short Answer
What is the purpose of wrapping UPDATE or DELETE statements in a transaction, and when would you use ROLLBACK?
Think about your answer, then reveal below.
Model answer: A transaction lets you verify the effect of a destructive statement before making it permanent. After executing the UPDATE or DELETE, you SELECT to check affected rows. If correct, COMMIT makes the change permanent. If something is wrong, ROLLBACK undoes the entire operation as if it never happened.
UPDATE and DELETE have no built-in undo outside a transaction. Wrapping in BEGIN...COMMIT creates a checkpoint: the changes are visible within your session but not yet to others. Only on COMMIT do they become permanent. If the WHERE clause matched more rows than expected — a common mistake — ROLLBACK lets you escape without data loss.