Read One Loan Across Three Tables

The member join answers who borrowed something, but the report still does not say what they borrowed. The loan already has the second path we need: loans.item_id points to items.id.

Open report.sql and keep the member join unchanged. Add a second join below it:

INNER JOIN items ON items.id = loans.item_id

These two ON comparisons are independent. One follows member_id to the member table. The other follows item_id to the item table. Reusing the member comparison for both tables would either produce the wrong record or no record at all.

Add the item code and name between the member columns and the dates:

items.asset_tag,
items.name AS item_name,

Both items and members have a column named name, so qualification matters here. members.name AS member_name and items.name AS item_name tell SQLite which value to read and give the result two unambiguous headings.

Press Run and trace the first line:

501 | MB-017 | Riley | IT-100 | Cordless drill | 2026-08-18 | NULL

Loan 501 supplies the center of that row. Its member ID finds Riley. Its item ID finds the cordless drill. The checkout and return values remain facts from the loan itself.

This is still one result row per loan, not a new combined table stored in the database. The query follows relationships while it runs and returns the selected view. Changing a member or item fact later would change the next report without rewriting historical loan rows.

Submit uses unrelated numeric IDs and repeated displayed names. A correct report must follow both ID comparisons, return exactly the seven documented columns, and keep ORDER BY loans.id. You already know the join pattern; this exercise asks you to keep two paths straight at the same time.