SQL enough to read a query

02A filter is not a sentence about the table

Read the clauses in their roles: FROM identifies the table, WHERE filters its rows, and SELECT names the columns returned. The SQL comparison active = 1 uses a single equals sign; Python used == for comparison. Judge punctuation in the language you are reading.

A row that fails the condition remains in the stored table. It is absent from the result, not deleted. Without ORDER BY, which requests a sort order, do not assume that returned rows have a guaranteed order. This activity asks for the set of matching names.

The SQL downloads also show CREATE TABLE, which defines columns, and INSERT, which adds rows. Those statements explain where the printed grid would come from if executed. Reading them changes nothing; executing them would create or change data. Text values in these examples use single quotes.

The optional Python snippet uses its sqlite3 module. connect(":memory:") creates a temporary database in the process’s memory; executescript runs the supplied SQL setup; execute runs the fixed SELECT. The for loop receives result rows, and row[0] selects the first column. These calls are background for the snippet, not requirements for the paper activity. Values from users should be passed with bound placeholders, a way to supply data separately from SQL instructions, rather than joined into SQL text.

lane  1
om  0
paz  1

03Keep the active rows from the members card

Use the activity grid containing ada, bo, and cy. First evaluate the condition by hand; then compare with the SQL source that describes those same rows. The required question later supplies a different pair of names.

YanoSec / Code
Original members table. No database was opened.

column name | column active
ada         | 1
bo          | 0
cy          | 1

Each data line is a row. name and active are columns.
Query to read, not to run here:
SELECT name FROM members WHERE active = 1;
Rows whose active value is 1: ada and cy.
bo has active 0, so the predicate leaves bo out.
Row order is not part of this check. SELECT does not change the table.
Apply the condition independently to every row in a new table.

CREATE TABLE members (
  name TEXT NOT NULL,
  active INTEGER NOT NULL
);
INSERT INTO members (name, active) VALUES ('ada', 1);
INSERT INTO members (name, active) VALUES ('bo', 0);
INSERT INTO members (name, active) VALUES ('cy', 1);

Optional later snippet, not run:
import sqlite3
connection = sqlite3.connect(":memory:")
connection.executescript(open("members.sql", encoding="utf-8").read())
for row in connection.execute("SELECT name FROM members WHERE active = 1"):
    print(row[0])
Predicted kept names: ada and cy.
Order is not part of the check. Close the process when you stop; there is no server.

1. In table.txt, read each name with its active value. ada has 1, bo has 0, and cy has 1.
2. Apply active = 1 separately to each row. Compare with the supplied result set: ada and cy. bo remains stored but does not appear in this result.
3. Read the INSERT lines in members.sql and match each name and active value with the grid. They describe the same three records.
4. Stop with a written explanation of the kept rows. No SQLite launch is needed. If you later use the optional snippet, use only these supplied files in a fresh lab directory; its database is in memory and ends with the process.

04Page and table case

Use the stage case to connect representation, JavaScript, and a query. The HTML and SQL are separate files, and the text card supplies both the table and the predicted page change. Make your predictions before comparing with its rubric.

YanoSec / Code
Stage case for representation, a page script, and a table.
Self-review case. The page and query results below are predictions.
A file URL is not HTTP. The SQL file is not part of the HTML file.

Representation:
The displayed word desk-lead uses nine ASCII characters.
UTF-8 stores those nine characters as nine bytes.
Counting characters and counting bytes agree for this ASCII word.
They do not agree for every word, as the Unicode lesson showed.

Page script:
Before the click, #role text is reader.
The click handler sets textContent to desk-lead.
Predicted DOM text after the click: desk-lead.
The script does not open the SQL file and does not send a request.

Table:
name | lane
ria  | a
sol  | b
tez  | a
Query: SELECT name FROM shifts WHERE lane = 'a';
Kept rows: ria and tez. sol is left out.
SELECT does not change the stored rows.

Boundary:
Changing the paragraph does not change the shifts table.
Changing a row would not change the paragraph unless some other,
absent program copied it. This case has no such program.
No server permission is granted by the new label.

Rubric: name the byte count for desk-lead, the DOM text after the click,
the kept names, and the store the click does not modify.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Desk role</title>
</head>
<body>
  <p id="role">reader</p>
  <button id="promote" type="button">Change the label</button>
  <script>
    document.querySelector("#promote").addEventListener("click", function () {
      document.querySelector("#role").textContent = "desk-lead";
    });
  </script>
</body>
</html>

CREATE TABLE shifts (
  name TEXT NOT NULL,
  lane TEXT NOT NULL
);
INSERT INTO shifts (name, lane) VALUES ('ria', 'a');
INSERT INTO shifts (name, lane) VALUES ('sol', 'b');
INSERT INTO shifts (name, lane) VALUES ('tez', 'a');

1. Count the ASCII characters in desk-lead. Check: 9 characters and 9 UTF-8 bytes. Explain why this agreement depends on the characters being ASCII.
2. Follow the HTML click handler: it replaces reader with desk-lead in the role paragraph. It neither opens the SQL file nor sends a request.
3. Use the printed shifts grid and apply WHERE lane = 'a'. Check: ria and tez match; sol does not. SELECT returns matching rows without changing the stored table.
4. Write an evidence note with the byte count, predicted DOM text, matching names, and the state the click does not change. The paragraph and table remain separate; the new label grants no server permission. Stop without executing either file.

05Stage evidence

Your evidence note should connect each result to its source: count pairs for byte size, apply a declared decoding rule, follow a script’s read and write operations, trace a DOM assignment, and evaluate a table condition. These are related reading skills, but each uses a different kind of evidence. The supplied tables and page traces let you practise them in a browser. Running Python, activating the local page, and executing SQL are separate practical experiences; a correct prediction alone does not demonstrate those operations.

06Optional challenge

Spend about ten extra minutes changing the activity condition in notes to active = 0. The matching set should contain only bo. Explain why ada and cy still remain in the stored table even though this new result leaves them out.

07Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

members_demo
name | active | team
Fia | 0 | red
Gus | 1 | blue
Hui | 1 | red
Ike | 0 | blue
Query: SELECT name FROM members_demo WHERE active = 0;
No ORDER BY is present. This is a paper prediction.

members_demo
name | active
Jen | 1
Kit | 0
Lou | 0
Query: SELECT name FROM members_demo WHERE active = 1;
Change only the condition to active = 0. No INSERT, UPDATE or DELETE is performed.

08Explain your prediction

Optional written self-check: Explain FROM, WHERE and SELECT separately. Distinguish a result from stored rows, avoid claiming a guaranteed order without ORDER BY, and keep SQL table changes separate from browser display and file bytes.