Technical skill practice

SQL DELETE: Remove the Intended Rows and Keep the Table

DELETE removes rows that satisfy its condition. It leaves the table definition in place. Define the retained and removed populations explicitly, then verify examples from both sets in an isolated exercise.

The practice task

Remove cancelled entries from a fictional workshop queue while retaining a pending entry and an approved entry. The complete example creates a fresh toy table before performing the deletion.

The data below is fictional. Run the example in a new SQLite database. It was checked with SQLite 3.51.0; other databases may use different syntax, functions or type rules.

Complete worked query

Create the small fixture and run the query together. The IDs, boundary values and missing entries make the result small enough to check by hand.

CREATE TABLE workshop_queue(id INTEGER, status TEXT);
INSERT INTO workshop_queue VALUES (1,'cancelled'),(2,'pending'),(3,'approved');
DELETE FROM workshop_queue WHERE status = 'cancelled';

SELECT id, status FROM workshop_queue ORDER BY id;

Checked result

This is the result of the exact example above. NULL marks a missing database value rather than the text string "NULL".

Result rows

id | status

2 | pending

3 | approved

Read the result

The cancelled entry is gone, while the pending and approved entries remain. The final SELECT works against the same table, demonstrating that deleting a subset of rows does not remove the table itself.

Previewing the same WHERE condition with SELECT is a useful way to inspect the intended target set before adapting a deletion. A missing condition changes the task to deleting all rows. A wrong condition can remove a convincing-looking but unintended subset.

Actual databases can have foreign keys, triggers and retention requirements that change what a deletion permits or causes. This fixture has none of those dependencies. Treat its result as a demonstration of the row-selection rule, not evidence about an unrelated live application schema.

Mistakes to check

Use these checks when adapting the example to a different dataset.

  • Check a record that should be removed and records that should remain.
  • Keep deletion distinct from dropping the table definition.
  • Inspect dependencies before applying the idea outside a disposable example.

Questions, answered

Can I run this example as written?

Yes, in a new SQLite database using the schema and values shown. The result above was checked with SQLite 3.51.0. Keep it separate from an existing database.

Does a successful DELETE always mean a record matched?

No. A valid condition can match zero rows. Inspect the intended record set or the relevant affected-row information rather than inferring a match from the absence of an error.

Sources and examples

ResumizeAI team. Examples are fictional teaching material, not customer results. Replace sample details with your own facts.

Your experience. A complete resume.

Build in Resumize with ATS-friendly templates, guided editing and a live preview. Start free, then upgrade when you need more.

Free account required. Free-plan PDF exports include a watermark.