Require the Facts an Item Needs

An item with ID 51 and asset tag CAMERA-07 reaches the catalog without a name:

NULL is SQLite’s marker for no stored value. The current name TEXT declaration gives the column a text affinity, but it does not require a value. SQLite would accept this incomplete record unless the schema adds another rule.

NOT NULL tells SQLite that a column must have a value.

Require all four facts

Open schema.sql and add NOT NULL after the declared type of asset_tag, name, category, and loan_days. Keep id INTEGER PRIMARY KEY unchanged.

Here is the complete schema you are building:

CREATE TABLE items (
    id INTEGER PRIMARY KEY,
    asset_tag TEXT NOT NULL,
    name TEXT NOT NULL,
    category TEXT NOT NULL,
    loan_days INTEGER NOT NULL
);

Press Run and read the complete definition SQLite prints. You should see NOT NULL on all four changed lines.

Read one of those lines from left to right. In name TEXT NOT NULL, name identifies the column, TEXT remains its affinity, and NOT NULL adds the requirement. The same pattern protects the other three facts.

Press Submit when the schema loads successfully. The submission tries a record with NULL as its asset tag, then separate records with NULL as the name, category, and loan period. SQLite must reject each one. The example above shows the missing name, but protecting only name would leave the other three gaps open.

If one of those cases is still accepted, compare that column’s complete declaration with the schema above. The missing NOT NULL belongs on the line for the value that slipped through.

NOT NULL has a precise job. It rejects the absence of a value. It does not decide whether supplied text is useful, so an empty piece of text is a different problem from NULL.

This rule also says nothing about repeated non-NULL values. Two records can still carry the same asset tag, even though a tag is meant to identify one physical item. You have required the important facts; next you will protect the tag from being reused.