SQL Not Equal: Understand the Missing-Value Case

The practice task

List support tickets that are not closed, including tickets whose status has not yet been set. The task distinguishes a known open status from an unknown status while retaining both for review.

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 tickets(id INTEGER, status TEXT);
INSERT INTO tickets VALUES (1,'open'),(2,'closed'),(3,NULL),(4,'waiting');

SELECT id, status FROM tickets
WHERE status <> 'closed' OR status IS NULL
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".

Read the result

The <> comparison retains open and waiting. The separate IS NULL condition retains ticket 3. Removing that condition would exclude the unknown status because ordinary comparison with NULL does not establish a true not-equal result.

Including unknowns is a deliberate reporting choice. For a list of confirmed active tickets, the analyst might instead exclude unknown status and report those records separately for cleanup. The right filter depends on the question, not on a universal preference for including NULL.

The standard <> spelling is a useful default across SQL products. Some engines also accept !=, but changing the operator spelling does not change the missing-value decision. Test null behavior rather than assuming an alternative spelling fixes it.

Mistakes to check

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

• Do not compare a value with = NULL or <> NULL.
• Keep parentheses when combining this condition with additional AND filters.
• Separate unknown status from a known business state in downstream summaries.