How to Master SQLite STRICT Tables in Punggol Tuition

PUNGGOL TUITION · PRACTICAL MASTERY GUIDE

If a learner expects every SQLite INTEGER column to reject text automatically, the surprise is not a bug: ordinary SQLite uses flexible typing. STRICT tables make storage-class rules explicit for one table while preserving SQLite’s broader constraint and file-format model.

The essential rule is that ) STRICT follows the table definition, every column needs one of INT, INTEGER, REAL, TEXT, BLOB or ANY, non-ANY values must store in the declared type after any lossless coercion, and ANY preserves its exact storage class. Primary keys, integrity checks and version compatibility add important boundaries.

This guide treats SQLite STRICT Tables as a reasoning skill. It begins with the governing model, moves through worked examples and diagnostic routes, and ends with transfer cases, practice with explained answers, parent decisions and FAQs. The examples are proposed home or lesson activities; they are not claims about a physical Punggol branch, school affiliation, timetable, class size, fee or guaranteed result.

For a Punggol family, the practical aim is simple: a learner should be able to use a short study block before schoolwork, after CCA, or during a weekend library session without needing a large project. Each chapter is designed so the smallest useful example can be completed, discussed and saved as a test fixture.

The official technical reference for this article is Official SQLite STRICT Tables documentation. Where the feature is version-sensitive or still developing, the article states that boundary explicitly. Examples were independently checked against the runtime or specification named in the reference section.

Choose a reading route

If the immediate concern is “I can copy the syntax but I cannot explain the result”, use the first route. If a real project is already failing, use the diagnostic route. Parents can use the final route to decide whether more practice, a smaller prerequisite or a different example is needed. For the wider learning framework, see How Studying Works.

Start from the model: Chapters 1–4. Begin with Flexible typing is the baseline and continue in order to The version boundary is 3.37.0.

Diagnose a confusing result: Chapters 5–8. Begin with Every column needs a datatype and continue in order to Datatype constraint failures.

Build reliable examples: Chapters 9–12. Begin with NULL follows ordinary constraints and continue in order to INT PRIMARY KEY is different.

Transfer to real work: Chapters 13–16. Begin with ANY preserves the exact storage class and continue in order to quick_check also includes type checking.

Decide and teach: Chapters 17–20. Begin with Other constraints keep their semantics and continue in order to Choosing STRICT for the right job.

Open the full 20-chapter index

1. Flexible typing is the baseline
2. STRICT appears after the closing parenthesis
3. Strictness is table by table
4. The version boundary is 3.37.0
5. Every column needs a datatype
6. The allowed type names
7. Lossless coercion still happens
8. Datatype constraint failures
9. NULL follows ordinary constraints
10. Primary-key columns are implicitly not null
11. INTEGER PRIMARY KEY keeps rowid behaviour
12. INT PRIMARY KEY is different
13. ANY preserves the exact storage class
14. Ordinary ANY can still coerce
15. integrity_check verifies strict column types
16. quick_check also includes type checking
17. Other constraints keep their semantics
18. Same on-disk format, older-parser boundary
19. Migrate with a typed import path
20. Choosing STRICT for the right job

CHAPTER 1 OF 20 · Back to contents

1. Flexible typing is the baseline

The short answer: Ordinary SQLite tables usually preserve values that cannot be converted losslessly to the column affinity. The governing rule is: STRICT is an opt-in table mode, not a database-wide replacement for SQLite’s flexible model.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Understanding the baseline explains why STRICT changes failed inserts rather than merely adding documentation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the flexible typing is the baseline example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE ordinary(qty INTEGER);
INSERT INTO ordinary VALUES('xyz');
SELECT qty, typeof(qty) FROM ordinary;

Expected result and reasoning. An ordinary table can store the text xyz in the INTEGER-affinity column. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Calling all SQLite columns rigid by default imports another database engine’s model. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Is this table declared STRICT?”

Evidence to collect: the exact input, environment version, observed result and the rule for flexible typing is the baseline
Variable to hold constant: the surrounding setup, so the comparison isolates flexible typing is the baseline.
Variable to change: repeat with a STRICT table
Explanation standard: name the rule, not merely the successful command or copied syntax.

For flexible typing is the baseline, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a homework tracker. Transfer flexible typing is the baseline into a homework tracker. Preserve the governing rule—STRICT is an opt-in table mode, not a database-wide replacement for SQLite’s flexible model.—while identifying what changes in this setting. Ordinary SQLite tables usually preserve values that cannot be converted losslessly to the column affinity. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT is an opt-in table mode, not a database-wide replacement for SQLite’s flexible model.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a small science dataset. Transfer flexible typing is the baseline into a small science dataset. Preserve the governing rule—STRICT is an opt-in table mode, not a database-wide replacement for SQLite’s flexible model.—while identifying what changes in this setting. Ordinary SQLite tables usually preserve values that cannot be converted losslessly to the column affinity. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT is an opt-in table mode, not a database-wide replacement for SQLite’s flexible model.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a migration rehearsal. Transfer flexible typing is the baseline into a migration rehearsal. Preserve the governing rule—STRICT is an opt-in table mode, not a database-wide replacement for SQLite’s flexible model.—while identifying what changes in this setting. Ordinary SQLite tables usually preserve values that cannot be converted losslessly to the column affinity. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT is an opt-in table mode, not a database-wide replacement for SQLite’s flexible model.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a test database. Transfer flexible typing is the baseline into a test database. Preserve the governing rule—STRICT is an opt-in table mode, not a database-wide replacement for SQLite’s flexible model.—while identifying what changes in this setting. Ordinary SQLite tables usually preserve values that cannot be converted losslessly to the column affinity. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT is an opt-in table mode, not a database-wide replacement for SQLite’s flexible model.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for flexible typing is the baseline, predict the result, then repeat with a STRICT table. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. An ordinary table can store the text xyz in the INTEGER-affinity column. The contrast is explained by this rule: STRICT is an opt-in table mode, not a database-wide replacement for SQLite’s flexible model. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for flexible typing is the baseline, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain flexible typing is the baseline, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Contents · Full contents · Next: STRICT appears after the closing parenthesis →

CHAPTER 2 OF 20 · Back to contents

2. STRICT appears after the closing parenthesis

The short answer: The table option keyword follows the complete column-and-constraint list. The governing rule is: Write ) STRICT, not STRICT inside a column definition.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The parser applies the mode to the whole table created by that statement. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the strict appears after the closing parenthesis example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE lesson(
  id INTEGER PRIMARY KEY,
  title TEXT NOT NULL
) STRICT;

Expected result and reasoning. SQLite 3.37+ creates a strict table. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Writing title TEXT STRICT attempts to use STRICT in the wrong grammar position. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for strict appears after the closing parenthesis
Variable to hold constant: the surrounding setup, so the comparison isolates strict appears after the closing parenthesis.
Variable to change: move STRICT inside the parentheses to see the syntax failure
Explanation standard: name the rule, not merely the successful command or copied syntax.

For strict appears after the closing parenthesis, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a reading log. Transfer strict appears after the closing parenthesis into a reading log. Preserve the governing rule—Write ) STRICT, not STRICT inside a column definition.—while identifying what changes in this setting. The table option keyword follows the complete column-and-constraint list. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Write ) STRICT, not STRICT inside a column definition.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a family budget prototype. Transfer strict appears after the closing parenthesis into a family budget prototype. Preserve the governing rule—Write ) STRICT, not STRICT inside a column definition.—while identifying what changes in this setting. The table option keyword follows the complete column-and-constraint list. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Write ) STRICT, not STRICT inside a column definition.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an import validator. Transfer strict appears after the closing parenthesis into an import validator. Preserve the governing rule—Write ) STRICT, not STRICT inside a column definition.—while identifying what changes in this setting. The table option keyword follows the complete column-and-constraint list. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Write ) STRICT, not STRICT inside a column definition.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an application schema review. Transfer strict appears after the closing parenthesis into an application schema review. Preserve the governing rule—Write ) STRICT, not STRICT inside a column definition.—while identifying what changes in this setting. The table option keyword follows the complete column-and-constraint list. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Write ) STRICT, not STRICT inside a column definition.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for strict appears after the closing parenthesis, predict the result, then move STRICT inside the parentheses to see the syntax failure. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. SQLite 3.37+ creates a strict table. The contrast is explained by this rule: Write ) STRICT, not STRICT inside a column definition. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for strict appears after the closing parenthesis, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain strict appears after the closing parenthesis, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Flexible typing is the baseline · Full contents · Next: Strictness is table by table →

CHAPTER 3 OF 20 · Back to contents

3. Strictness is table by table

The short answer: One database can contain strict and ordinary tables together. The governing rule is: Each CREATE TABLE statement makes its own typing decision.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

This supports incremental migration and mixed compatibility, but reviewers must inspect each table rather than assume a global switch. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the strictness is table by table example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE old_data(v INTEGER);
CREATE TABLE new_data(v INTEGER) STRICT;

Expected result and reasoning. Both tables coexist; only new_data enforces STRICT rules. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Calling the file a strict database hides the ordinary table. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for strictness is table by table
Variable to hold constant: the surrounding setup, so the comparison isolates strictness is table by table.
Variable to change: query sqlite_schema for both SQL definitions
Explanation standard: name the rule, not merely the successful command or copied syntax.

For strictness is table by table, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a small science dataset. Transfer strictness is table by table into a small science dataset. Preserve the governing rule—Each CREATE TABLE statement makes its own typing decision.—while identifying what changes in this setting. One database can contain strict and ordinary tables together. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Each CREATE TABLE statement makes its own typing decision.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a migration rehearsal. Transfer strictness is table by table into a migration rehearsal. Preserve the governing rule—Each CREATE TABLE statement makes its own typing decision.—while identifying what changes in this setting. One database can contain strict and ordinary tables together. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Each CREATE TABLE statement makes its own typing decision.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a test database. Transfer strictness is table by table into a test database. Preserve the governing rule—Each CREATE TABLE statement makes its own typing decision.—while identifying what changes in this setting. One database can contain strict and ordinary tables together. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Each CREATE TABLE statement makes its own typing decision.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a homework tracker. Transfer strictness is table by table into a homework tracker. Preserve the governing rule—Each CREATE TABLE statement makes its own typing decision.—while identifying what changes in this setting. One database can contain strict and ordinary tables together. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Each CREATE TABLE statement makes its own typing decision.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for strictness is table by table, predict the result, then query sqlite_schema for both SQL definitions. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Both tables coexist; only new_data enforces STRICT rules. The contrast is explained by this rule: Each CREATE TABLE statement makes its own typing decision. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for strictness is table by table, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain strictness is table by table, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: STRICT appears after the closing parenthesis · Full contents · Next: The version boundary is 3.37.0 →

CHAPTER 4 OF 20 · Back to contents

4. The version boundary is 3.37.0

The short answer: STRICT tables were introduced in SQLite 3.37.0 on 27 November 2021. The governing rule is: Check the library version used by the application, not only a separate command-line tool.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Embedded applications may bundle a different SQLite library from the system shell. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the the version boundary is 3.37.0 example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

SELECT sqlite_version();

Expected result and reasoning. A runtime at 3.37.0 or later understands the table option; the verified fixture used SQLite 3.53.1. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Checking sqlite3 –version while the application uses another binding can give false confidence. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for the version boundary is 3.37.0
Variable to hold constant: the surrounding setup, so the comparison isolates the version boundary is 3.37.0.
Variable to change: print sqlite_version() through the application connection
Explanation standard: name the rule, not merely the successful command or copied syntax.

For the version boundary is 3.37.0, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a family budget prototype. Transfer the version boundary is 3.37.0 into a family budget prototype. Preserve the governing rule—Check the library version used by the application, not only a separate command-line tool.—while identifying what changes in this setting. STRICT tables were introduced in SQLite 3.37.0 on 27 November 2021. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Check the library version used by the application, not only a separate command-line tool.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an import validator. Transfer the version boundary is 3.37.0 into an import validator. Preserve the governing rule—Check the library version used by the application, not only a separate command-line tool.—while identifying what changes in this setting. STRICT tables were introduced in SQLite 3.37.0 on 27 November 2021. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Check the library version used by the application, not only a separate command-line tool.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an application schema review. Transfer the version boundary is 3.37.0 into an application schema review. Preserve the governing rule—Check the library version used by the application, not only a separate command-line tool.—while identifying what changes in this setting. STRICT tables were introduced in SQLite 3.37.0 on 27 November 2021. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Check the library version used by the application, not only a separate command-line tool.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a reading log. Transfer the version boundary is 3.37.0 into a reading log. Preserve the governing rule—Check the library version used by the application, not only a separate command-line tool.—while identifying what changes in this setting. STRICT tables were introduced in SQLite 3.37.0 on 27 November 2021. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Check the library version used by the application, not only a separate command-line tool.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for the version boundary is 3.37.0, predict the result, then print sqlite_version() through the application connection. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A runtime at 3.37.0 or later understands the table option; the verified fixture used SQLite 3.53.1. The contrast is explained by this rule: Check the library version used by the application, not only a separate command-line tool. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for the version boundary is 3.37.0, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain the version boundary is 3.37.0, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Strictness is table by table · Full contents · Next: Every column needs a datatype →

CHAPTER 5 OF 20 · Back to contents

5. Every column needs a datatype

The short answer: STRICT removes the ability to leave a column type blank. The governing rule is: Declare one allowed datatype for every column.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The schema becomes explicit at the point of definition, helping imports and reviews fail early. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the every column needs a datatype example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE strict_notes(id INTEGER, note) STRICT;

Expected result and reasoning. The statement fails because note has no declared datatype. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming a missing type means ANY ignores the rule. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for every column needs a datatype
Variable to hold constant: the surrounding setup, so the comparison isolates every column needs a datatype.
Variable to change: change note to note ANY
Explanation standard: name the rule, not merely the successful command or copied syntax.

For every column needs a datatype, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a migration rehearsal. Transfer every column needs a datatype into a migration rehearsal. Preserve the governing rule—Declare one allowed datatype for every column.—while identifying what changes in this setting. STRICT removes the ability to leave a column type blank. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Declare one allowed datatype for every column.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a test database. Transfer every column needs a datatype into a test database. Preserve the governing rule—Declare one allowed datatype for every column.—while identifying what changes in this setting. STRICT removes the ability to leave a column type blank. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Declare one allowed datatype for every column.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a homework tracker. Transfer every column needs a datatype into a homework tracker. Preserve the governing rule—Declare one allowed datatype for every column.—while identifying what changes in this setting. STRICT removes the ability to leave a column type blank. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Declare one allowed datatype for every column.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a small science dataset. Transfer every column needs a datatype into a small science dataset. Preserve the governing rule—Declare one allowed datatype for every column.—while identifying what changes in this setting. STRICT removes the ability to leave a column type blank. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Declare one allowed datatype for every column.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for every column needs a datatype, predict the result, then change note to note ANY. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The statement fails because note has no declared datatype. The contrast is explained by this rule: Declare one allowed datatype for every column. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for every column needs a datatype, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain every column needs a datatype, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: The version boundary is 3.37.0 · Full contents · Next: The allowed type names →

CHAPTER 6 OF 20 · Back to contents

6. The allowed type names

The short answer: STRICT initially accepts INT, INTEGER, REAL, TEXT, BLOB and ANY. The governing rule is: Names such as VARCHAR(50), BOOLEAN and DATETIME are not on the STRICT allow-list.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

SQLite keeps the initial set intentionally small; semantic constraints can be added separately. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the the allowed type names example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE s(a INT,b INTEGER,c REAL,d TEXT,e BLOB,f ANY) STRICT;

Expected result and reasoning. The six declared types are valid. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using VARCHAR because it is familiar from another engine causes a schema error. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for the allowed type names
Variable to hold constant: the surrounding setup, so the comparison isolates the allowed type names.
Variable to change: replace TEXT with VARCHAR(50)
Explanation standard: name the rule, not merely the successful command or copied syntax.

For the allowed type names, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: an import validator. Transfer the allowed type names into an import validator. Preserve the governing rule—Names such as VARCHAR(50), BOOLEAN and DATETIME are not on the STRICT allow-list.—while identifying what changes in this setting. STRICT initially accepts INT, INTEGER, REAL, TEXT, BLOB and ANY. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Names such as VARCHAR(50), BOOLEAN and DATETIME are not on the STRICT allow-list.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an application schema review. Transfer the allowed type names into an application schema review. Preserve the governing rule—Names such as VARCHAR(50), BOOLEAN and DATETIME are not on the STRICT allow-list.—while identifying what changes in this setting. STRICT initially accepts INT, INTEGER, REAL, TEXT, BLOB and ANY. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Names such as VARCHAR(50), BOOLEAN and DATETIME are not on the STRICT allow-list.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a reading log. Transfer the allowed type names into a reading log. Preserve the governing rule—Names such as VARCHAR(50), BOOLEAN and DATETIME are not on the STRICT allow-list.—while identifying what changes in this setting. STRICT initially accepts INT, INTEGER, REAL, TEXT, BLOB and ANY. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Names such as VARCHAR(50), BOOLEAN and DATETIME are not on the STRICT allow-list.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a family budget prototype. Transfer the allowed type names into a family budget prototype. Preserve the governing rule—Names such as VARCHAR(50), BOOLEAN and DATETIME are not on the STRICT allow-list.—while identifying what changes in this setting. STRICT initially accepts INT, INTEGER, REAL, TEXT, BLOB and ANY. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Names such as VARCHAR(50), BOOLEAN and DATETIME are not on the STRICT allow-list.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for the allowed type names, predict the result, then replace TEXT with VARCHAR(50). Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The six declared types are valid. The contrast is explained by this rule: Names such as VARCHAR(50), BOOLEAN and DATETIME are not on the STRICT allow-list. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for the allowed type names, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain the allowed type names, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Every column needs a datatype · Full contents · Next: Lossless coercion still happens →

CHAPTER 7 OF 20 · Back to contents

7. Lossless coercion still happens

The short answer: STRICT does not forbid every cross-type input; it attempts lossless conversion. The governing rule is: A numeric text that converts without loss can be stored as INTEGER.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

SQLite applies its usual affinity conversion, then verifies that the stored result conforms. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the lossless coercion still happens example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE s(qty INT) STRICT;
INSERT INTO s VALUES('42');
SELECT qty, typeof(qty) FROM s;

Expected result and reasoning. The verified SQLite 3.53.1 fixture stored 42 with type integer. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Saying strict means no coercion predicts an error the engine does not raise. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for lossless coercion still happens
Variable to hold constant: the surrounding setup, so the comparison isolates lossless coercion still happens.
Variable to change: compare ’42’ with ‘not-int’
Explanation standard: name the rule, not merely the successful command or copied syntax.

For lossless coercion still happens, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a test database. Transfer lossless coercion still happens into a test database. Preserve the governing rule—A numeric text that converts without loss can be stored as INTEGER.—while identifying what changes in this setting. STRICT does not forbid every cross-type input; it attempts lossless conversion. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A numeric text that converts without loss can be stored as INTEGER.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a homework tracker. Transfer lossless coercion still happens into a homework tracker. Preserve the governing rule—A numeric text that converts without loss can be stored as INTEGER.—while identifying what changes in this setting. STRICT does not forbid every cross-type input; it attempts lossless conversion. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A numeric text that converts without loss can be stored as INTEGER.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a small science dataset. Transfer lossless coercion still happens into a small science dataset. Preserve the governing rule—A numeric text that converts without loss can be stored as INTEGER.—while identifying what changes in this setting. STRICT does not forbid every cross-type input; it attempts lossless conversion. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A numeric text that converts without loss can be stored as INTEGER.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a migration rehearsal. Transfer lossless coercion still happens into a migration rehearsal. Preserve the governing rule—A numeric text that converts without loss can be stored as INTEGER.—while identifying what changes in this setting. STRICT does not forbid every cross-type input; it attempts lossless conversion. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A numeric text that converts without loss can be stored as INTEGER.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for lossless coercion still happens, predict the result, then compare ’42’ with ‘not-int’. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified SQLite 3.53.1 fixture stored 42 with type integer. The contrast is explained by this rule: A numeric text that converts without loss can be stored as INTEGER. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for lossless coercion still happens, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain lossless coercion still happens, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: The allowed type names · Full contents · Next: Datatype constraint failures →

CHAPTER 8 OF 20 · Back to contents

8. Datatype constraint failures

The short answer: A value that cannot be losslessly converted is rejected. The governing rule is: The failure is SQLITE_CONSTRAINT_DATATYPE rather than silent storage under another type.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The check protects the declared storage-class contract at write time. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the datatype constraint failures example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE s(qty INT) STRICT;
INSERT INTO s VALUES('not-int');

Expected result and reasoning. The verified fixture raised an IntegrityError whose message said a TEXT value could not be stored in the INT column. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Catching every constraint error as a duplicate-key problem hides the real repair. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for datatype constraint failures
Variable to hold constant: the surrounding setup, so the comparison isolates datatype constraint failures.
Variable to change: log the extended error information through the binding
Explanation standard: name the rule, not merely the successful command or copied syntax.

For datatype constraint failures, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: an application schema review. Transfer datatype constraint failures into an application schema review. Preserve the governing rule—The failure is SQLITE_CONSTRAINT_DATATYPE rather than silent storage under another type.—while identifying what changes in this setting. A value that cannot be losslessly converted is rejected. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The failure is SQLITE_CONSTRAINT_DATATYPE rather than silent storage under another type.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a reading log. Transfer datatype constraint failures into a reading log. Preserve the governing rule—The failure is SQLITE_CONSTRAINT_DATATYPE rather than silent storage under another type.—while identifying what changes in this setting. A value that cannot be losslessly converted is rejected. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The failure is SQLITE_CONSTRAINT_DATATYPE rather than silent storage under another type.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a family budget prototype. Transfer datatype constraint failures into a family budget prototype. Preserve the governing rule—The failure is SQLITE_CONSTRAINT_DATATYPE rather than silent storage under another type.—while identifying what changes in this setting. A value that cannot be losslessly converted is rejected. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The failure is SQLITE_CONSTRAINT_DATATYPE rather than silent storage under another type.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an import validator. Transfer datatype constraint failures into an import validator. Preserve the governing rule—The failure is SQLITE_CONSTRAINT_DATATYPE rather than silent storage under another type.—while identifying what changes in this setting. A value that cannot be losslessly converted is rejected. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The failure is SQLITE_CONSTRAINT_DATATYPE rather than silent storage under another type.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for datatype constraint failures, predict the result, then log the extended error information through the binding. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified fixture raised an IntegrityError whose message said a TEXT value could not be stored in the INT column. The contrast is explained by this rule: The failure is SQLITE_CONSTRAINT_DATATYPE rather than silent storage under another type. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for datatype constraint failures, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain datatype constraint failures, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Lossless coercion still happens · Full contents · Next: NULL follows ordinary constraints →

CHAPTER 9 OF 20 · Back to contents

9. NULL follows ordinary constraints

The short answer: STRICT typing does not automatically make every column NOT NULL. The governing rule is: NULL is accepted unless a NOT NULL or primary-key rule forbids it.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Nullability and storage type are separate parts of the schema contract. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the null follows ordinary constraints example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE s(note TEXT) STRICT;
INSERT INTO s VALUES(NULL);

Expected result and reasoning. The insert succeeds because note has no NOT NULL constraint. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming strict means all values must be present confuses missingness with type. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for null follows ordinary constraints
Variable to hold constant: the surrounding setup, so the comparison isolates null follows ordinary constraints.
Variable to change: add NOT NULL and repeat
Explanation standard: name the rule, not merely the successful command or copied syntax.

For null follows ordinary constraints, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a homework tracker. Transfer null follows ordinary constraints into a homework tracker. Preserve the governing rule—NULL is accepted unless a NOT NULL or primary-key rule forbids it.—while identifying what changes in this setting. STRICT typing does not automatically make every column NOT NULL. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “NULL is accepted unless a NOT NULL or primary-key rule forbids it.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a small science dataset. Transfer null follows ordinary constraints into a small science dataset. Preserve the governing rule—NULL is accepted unless a NOT NULL or primary-key rule forbids it.—while identifying what changes in this setting. STRICT typing does not automatically make every column NOT NULL. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “NULL is accepted unless a NOT NULL or primary-key rule forbids it.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a migration rehearsal. Transfer null follows ordinary constraints into a migration rehearsal. Preserve the governing rule—NULL is accepted unless a NOT NULL or primary-key rule forbids it.—while identifying what changes in this setting. STRICT typing does not automatically make every column NOT NULL. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “NULL is accepted unless a NOT NULL or primary-key rule forbids it.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a test database. Transfer null follows ordinary constraints into a test database. Preserve the governing rule—NULL is accepted unless a NOT NULL or primary-key rule forbids it.—while identifying what changes in this setting. STRICT typing does not automatically make every column NOT NULL. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “NULL is accepted unless a NOT NULL or primary-key rule forbids it.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for null follows ordinary constraints, predict the result, then add NOT NULL and repeat. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The insert succeeds because note has no NOT NULL constraint. The contrast is explained by this rule: NULL is accepted unless a NOT NULL or primary-key rule forbids it. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for null follows ordinary constraints, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain null follows ordinary constraints, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Datatype constraint failures · Full contents · Next: Primary-key columns are implicitly not null →

CHAPTER 10 OF 20 · Back to contents

10. Primary-key columns are implicitly not null

The short answer: Every STRICT primary-key column carries an implicit NOT NULL rule. The governing rule is: Do not rely on NULL as a placeholder for a non-INTEGER primary key.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The primary-key contract is strengthened explicitly in STRICT tables. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the primary-key columns are implicitly not null example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE t(k INT PRIMARY KEY,v TEXT) STRICT;
INSERT INTO t(k,v) VALUES(NULL,'x');

Expected result and reasoning. The verified SQLite 3.53.1 fixture raised NOT NULL constraint failed for t.k. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Expecting auto-numbering from INT PRIMARY KEY confuses it with the special INTEGER spelling. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for primary-key columns are implicitly not null
Variable to hold constant: the surrounding setup, so the comparison isolates primary-key columns are implicitly not null.
Variable to change: change INT to INTEGER in a new table
Explanation standard: name the rule, not merely the successful command or copied syntax.

For primary-key columns are implicitly not null, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a reading log. Transfer primary-key columns are implicitly not null into a reading log. Preserve the governing rule—Do not rely on NULL as a placeholder for a non-INTEGER primary key.—while identifying what changes in this setting. Every STRICT primary-key column carries an implicit NOT NULL rule. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Do not rely on NULL as a placeholder for a non-INTEGER primary key.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a family budget prototype. Transfer primary-key columns are implicitly not null into a family budget prototype. Preserve the governing rule—Do not rely on NULL as a placeholder for a non-INTEGER primary key.—while identifying what changes in this setting. Every STRICT primary-key column carries an implicit NOT NULL rule. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Do not rely on NULL as a placeholder for a non-INTEGER primary key.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an import validator. Transfer primary-key columns are implicitly not null into an import validator. Preserve the governing rule—Do not rely on NULL as a placeholder for a non-INTEGER primary key.—while identifying what changes in this setting. Every STRICT primary-key column carries an implicit NOT NULL rule. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Do not rely on NULL as a placeholder for a non-INTEGER primary key.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an application schema review. Transfer primary-key columns are implicitly not null into an application schema review. Preserve the governing rule—Do not rely on NULL as a placeholder for a non-INTEGER primary key.—while identifying what changes in this setting. Every STRICT primary-key column carries an implicit NOT NULL rule. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Do not rely on NULL as a placeholder for a non-INTEGER primary key.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for primary-key columns are implicitly not null, predict the result, then change INT to INTEGER in a new table. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified SQLite 3.53.1 fixture raised NOT NULL constraint failed for t.k. The contrast is explained by this rule: Do not rely on NULL as a placeholder for a non-INTEGER primary key. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for primary-key columns are implicitly not null, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain primary-key columns are implicitly not null, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: NULL follows ordinary constraints · Full contents · Next: INTEGER PRIMARY KEY keeps rowid behaviour →

CHAPTER 11 OF 20 · Back to contents

11. INTEGER PRIMARY KEY keeps rowid behaviour

The short answer: NULL inserted into INTEGER PRIMARY KEY is converted to a unique integer. The governing rule is: The documented exception preserves ordinary SQLite rowid alias behaviour.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Exact declared-type spelling determines whether the column aliases the rowid. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the integer primary key keeps rowid behaviour example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE s(id INTEGER PRIMARY KEY,note TEXT) STRICT;
INSERT INTO s VALUES(NULL,'hello');
SELECT id FROM s;

Expected result and reasoning. The inserted row receives a generated integer identifier. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Calling this a contradiction of implicit NOT NULL misses the documented conversion before storage. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for integer primary key keeps rowid behaviour
Variable to hold constant: the surrounding setup, so the comparison isolates integer primary key keeps rowid behaviour.
Variable to change: insert a second NULL and compare generated IDs
Explanation standard: name the rule, not merely the successful command or copied syntax.

For integer primary key keeps rowid behaviour, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a small science dataset. Transfer integer primary key keeps rowid behaviour into a small science dataset. Preserve the governing rule—The documented exception preserves ordinary SQLite rowid alias behaviour.—while identifying what changes in this setting. NULL inserted into INTEGER PRIMARY KEY is converted to a unique integer. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The documented exception preserves ordinary SQLite rowid alias behaviour.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a migration rehearsal. Transfer integer primary key keeps rowid behaviour into a migration rehearsal. Preserve the governing rule—The documented exception preserves ordinary SQLite rowid alias behaviour.—while identifying what changes in this setting. NULL inserted into INTEGER PRIMARY KEY is converted to a unique integer. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The documented exception preserves ordinary SQLite rowid alias behaviour.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a test database. Transfer integer primary key keeps rowid behaviour into a test database. Preserve the governing rule—The documented exception preserves ordinary SQLite rowid alias behaviour.—while identifying what changes in this setting. NULL inserted into INTEGER PRIMARY KEY is converted to a unique integer. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The documented exception preserves ordinary SQLite rowid alias behaviour.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a homework tracker. Transfer integer primary key keeps rowid behaviour into a homework tracker. Preserve the governing rule—The documented exception preserves ordinary SQLite rowid alias behaviour.—while identifying what changes in this setting. NULL inserted into INTEGER PRIMARY KEY is converted to a unique integer. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The documented exception preserves ordinary SQLite rowid alias behaviour.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for integer primary key keeps rowid behaviour, predict the result, then insert a second NULL and compare generated IDs. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The inserted row receives a generated integer identifier. The contrast is explained by this rule: The documented exception preserves ordinary SQLite rowid alias behaviour. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for integer primary key keeps rowid behaviour, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain integer primary key keeps rowid behaviour, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Primary-key columns are implicitly not null · Full contents · Next: INT PRIMARY KEY is different →

CHAPTER 12 OF 20 · Back to contents

12. INT PRIMARY KEY is different

The short answer: INT PRIMARY KEY is not the rowid-alias spelling. The governing rule is: INT and INTEGER are both allowed types, but only INTEGER has the special rowid rule.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

SQLite preserves this long-standing lexical distinction inside STRICT mode. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the int primary key is different example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE t(k INT PRIMARY KEY,v TEXT) STRICT;
INSERT INTO t VALUES(NULL,'x');

Expected result and reasoning. The verified fixture rejected NULL rather than generating an ID. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Treating INT as a harmless abbreviation changes key behaviour. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for int primary key is different
Variable to hold constant: the surrounding setup, so the comparison isolates int primary key is different.
Variable to change: compare pragma table_info for INT and INTEGER tables
Explanation standard: name the rule, not merely the successful command or copied syntax.

For int primary key is different, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a family budget prototype. Transfer int primary key is different into a family budget prototype. Preserve the governing rule—INT and INTEGER are both allowed types, but only INTEGER has the special rowid rule.—while identifying what changes in this setting. INT PRIMARY KEY is not the rowid-alias spelling. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “INT and INTEGER are both allowed types, but only INTEGER has the special rowid rule.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an import validator. Transfer int primary key is different into an import validator. Preserve the governing rule—INT and INTEGER are both allowed types, but only INTEGER has the special rowid rule.—while identifying what changes in this setting. INT PRIMARY KEY is not the rowid-alias spelling. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “INT and INTEGER are both allowed types, but only INTEGER has the special rowid rule.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an application schema review. Transfer int primary key is different into an application schema review. Preserve the governing rule—INT and INTEGER are both allowed types, but only INTEGER has the special rowid rule.—while identifying what changes in this setting. INT PRIMARY KEY is not the rowid-alias spelling. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “INT and INTEGER are both allowed types, but only INTEGER has the special rowid rule.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a reading log. Transfer int primary key is different into a reading log. Preserve the governing rule—INT and INTEGER are both allowed types, but only INTEGER has the special rowid rule.—while identifying what changes in this setting. INT PRIMARY KEY is not the rowid-alias spelling. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “INT and INTEGER are both allowed types, but only INTEGER has the special rowid rule.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for int primary key is different, predict the result, then compare pragma table_info for INT and INTEGER tables. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified fixture rejected NULL rather than generating an ID. The contrast is explained by this rule: INT and INTEGER are both allowed types, but only INTEGER has the special rowid rule. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for int primary key is different, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain int primary key is different, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: INTEGER PRIMARY KEY keeps rowid behaviour · Full contents · Next: ANY preserves the exact storage class →

CHAPTER 13 OF 20 · Back to contents

13. ANY preserves the exact storage class

The short answer: ANY in a STRICT table accepts any storage class without coercion. The governing rule is: Use ANY when heterogeneous exact values are intentional.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

It is not an escape from all constraints: NOT NULL and other table rules still apply. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the any preserves the exact storage class example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE s(code ANY) STRICT;
INSERT INTO s VALUES('000123');
SELECT code, typeof(code) FROM s;

Expected result and reasoning. The verified fixture preserved 000123 as text. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Declaring everything ANY discards most of the validation benefit of STRICT. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for any preserves the exact storage class
Variable to hold constant: the surrounding setup, so the comparison isolates any preserves the exact storage class.
Variable to change: compare a TEXT code and an integer code
Explanation standard: name the rule, not merely the successful command or copied syntax.

For any preserves the exact storage class, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a migration rehearsal. Transfer any preserves the exact storage class into a migration rehearsal. Preserve the governing rule—Use ANY when heterogeneous exact values are intentional.—while identifying what changes in this setting. ANY in a STRICT table accepts any storage class without coercion. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use ANY when heterogeneous exact values are intentional.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a test database. Transfer any preserves the exact storage class into a test database. Preserve the governing rule—Use ANY when heterogeneous exact values are intentional.—while identifying what changes in this setting. ANY in a STRICT table accepts any storage class without coercion. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use ANY when heterogeneous exact values are intentional.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a homework tracker. Transfer any preserves the exact storage class into a homework tracker. Preserve the governing rule—Use ANY when heterogeneous exact values are intentional.—while identifying what changes in this setting. ANY in a STRICT table accepts any storage class without coercion. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use ANY when heterogeneous exact values are intentional.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a small science dataset. Transfer any preserves the exact storage class into a small science dataset. Preserve the governing rule—Use ANY when heterogeneous exact values are intentional.—while identifying what changes in this setting. ANY in a STRICT table accepts any storage class without coercion. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use ANY when heterogeneous exact values are intentional.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for any preserves the exact storage class, predict the result, then compare a TEXT code and an integer code. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified fixture preserved 000123 as text. The contrast is explained by this rule: Use ANY when heterogeneous exact values are intentional. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for any preserves the exact storage class, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain any preserves the exact storage class, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: INT PRIMARY KEY is different · Full contents · Next: Ordinary ANY can still coerce →

CHAPTER 14 OF 20 · Back to contents

14. Ordinary ANY can still coerce

The short answer: ANY outside a STRICT table follows ordinary affinity behaviour for numeric-looking text. The governing rule is: STRICT ANY and ordinary ANY do not have identical preservation semantics.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The strict-table rule explicitly disables coercion for ANY, while ordinary tables may convert a string such as 000123 to integer 123. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the ordinary any can still coerce example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE ordinary(code ANY);
CREATE TABLE strict_one(code ANY) STRICT;
INSERT INTO ordinary VALUES('000123');
INSERT INTO strict_one VALUES('000123');

Expected result and reasoning. The ordinary table may store integer 123; the strict table preserves text 000123. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming the type name alone determines behaviour ignores table mode. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for ordinary any can still coerce
Variable to hold constant: the surrounding setup, so the comparison isolates ordinary any can still coerce.
Variable to change: query quote(code), typeof(code) side by side
Explanation standard: name the rule, not merely the successful command or copied syntax.

For ordinary any can still coerce, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: an import validator. Transfer ordinary any can still coerce into an import validator. Preserve the governing rule—STRICT ANY and ordinary ANY do not have identical preservation semantics.—while identifying what changes in this setting. ANY outside a STRICT table follows ordinary affinity behaviour for numeric-looking text. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT ANY and ordinary ANY do not have identical preservation semantics.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an application schema review. Transfer ordinary any can still coerce into an application schema review. Preserve the governing rule—STRICT ANY and ordinary ANY do not have identical preservation semantics.—while identifying what changes in this setting. ANY outside a STRICT table follows ordinary affinity behaviour for numeric-looking text. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT ANY and ordinary ANY do not have identical preservation semantics.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a reading log. Transfer ordinary any can still coerce into a reading log. Preserve the governing rule—STRICT ANY and ordinary ANY do not have identical preservation semantics.—while identifying what changes in this setting. ANY outside a STRICT table follows ordinary affinity behaviour for numeric-looking text. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT ANY and ordinary ANY do not have identical preservation semantics.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a family budget prototype. Transfer ordinary any can still coerce into a family budget prototype. Preserve the governing rule—STRICT ANY and ordinary ANY do not have identical preservation semantics.—while identifying what changes in this setting. ANY outside a STRICT table follows ordinary affinity behaviour for numeric-looking text. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT ANY and ordinary ANY do not have identical preservation semantics.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for ordinary any can still coerce, predict the result, then query quote(code), typeof(code) side by side. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The ordinary table may store integer 123; the strict table preserves text 000123. The contrast is explained by this rule: STRICT ANY and ordinary ANY do not have identical preservation semantics. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for ordinary any can still coerce, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain ordinary any can still coerce, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: ANY preserves the exact storage class · Full contents · Next: integrity_check verifies strict column types →

CHAPTER 15 OF 20 · Back to contents

15. integrity_check verifies strict column types

The short answer: PRAGMA integrity_check examines stored types in STRICT tables. The governing rule is: Use it as a verification layer, not a substitute for schema design or tested imports.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The pragma can report values that violate the declared type contract if corruption or unsafe manipulation produced them. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the integrity_check verifies strict column types example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

PRAGMA integrity_check;

Expected result and reasoning. The verified fixture returned ok. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. An ok result does not prove application-level meanings such as valid date ranges or school IDs. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for integrity_check verifies strict column types
Variable to hold constant: the surrounding setup, so the comparison isolates integrity_check verifies strict column types.
Variable to change: add an appropriate CHECK constraint in a new fixture
Explanation standard: name the rule, not merely the successful command or copied syntax.

For integrity_check verifies strict column types, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a test database. Transfer integrity_check verifies strict column types into a test database. Preserve the governing rule—Use it as a verification layer, not a substitute for schema design or tested imports.—while identifying what changes in this setting. PRAGMA integrity_check examines stored types in STRICT tables. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use it as a verification layer, not a substitute for schema design or tested imports.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a homework tracker. Transfer integrity_check verifies strict column types into a homework tracker. Preserve the governing rule—Use it as a verification layer, not a substitute for schema design or tested imports.—while identifying what changes in this setting. PRAGMA integrity_check examines stored types in STRICT tables. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use it as a verification layer, not a substitute for schema design or tested imports.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a small science dataset. Transfer integrity_check verifies strict column types into a small science dataset. Preserve the governing rule—Use it as a verification layer, not a substitute for schema design or tested imports.—while identifying what changes in this setting. PRAGMA integrity_check examines stored types in STRICT tables. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use it as a verification layer, not a substitute for schema design or tested imports.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a migration rehearsal. Transfer integrity_check verifies strict column types into a migration rehearsal. Preserve the governing rule—Use it as a verification layer, not a substitute for schema design or tested imports.—while identifying what changes in this setting. PRAGMA integrity_check examines stored types in STRICT tables. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use it as a verification layer, not a substitute for schema design or tested imports.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for integrity_check verifies strict column types, predict the result, then add an appropriate CHECK constraint in a new fixture. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The verified fixture returned ok. The contrast is explained by this rule: Use it as a verification layer, not a substitute for schema design or tested imports. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for integrity_check verifies strict column types, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain integrity_check verifies strict column types, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Ordinary ANY can still coerce · Full contents · Next: quick_check also includes type checking →

CHAPTER 16 OF 20 · Back to contents

16. quick_check also includes type checking

The short answer: PRAGMA quick_check performs a faster set of checks and includes STRICT type validation. The governing rule is: Choose the pragma according to operational needs and document the trade-off.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Both are integrity tools; neither changes the data. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the quick_check also includes type checking example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

PRAGMA quick_check;

Expected result and reasoning. A sound small fixture returns ok. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Running quick_check immediately after every row without a reason can add cost without improving the model. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for quick_check also includes type checking
Variable to hold constant: the surrounding setup, so the comparison isolates quick_check also includes type checking.
Variable to change: run both on the same disposable database and record duration
Explanation standard: name the rule, not merely the successful command or copied syntax.

For quick_check also includes type checking, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: an application schema review. Transfer quick_check also includes type checking into an application schema review. Preserve the governing rule—Choose the pragma according to operational needs and document the trade-off.—while identifying what changes in this setting. PRAGMA quick_check performs a faster set of checks and includes STRICT type validation. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Choose the pragma according to operational needs and document the trade-off.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a reading log. Transfer quick_check also includes type checking into a reading log. Preserve the governing rule—Choose the pragma according to operational needs and document the trade-off.—while identifying what changes in this setting. PRAGMA quick_check performs a faster set of checks and includes STRICT type validation. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Choose the pragma according to operational needs and document the trade-off.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a family budget prototype. Transfer quick_check also includes type checking into a family budget prototype. Preserve the governing rule—Choose the pragma according to operational needs and document the trade-off.—while identifying what changes in this setting. PRAGMA quick_check performs a faster set of checks and includes STRICT type validation. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Choose the pragma according to operational needs and document the trade-off.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an import validator. Transfer quick_check also includes type checking into an import validator. Preserve the governing rule—Choose the pragma according to operational needs and document the trade-off.—while identifying what changes in this setting. PRAGMA quick_check performs a faster set of checks and includes STRICT type validation. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Choose the pragma according to operational needs and document the trade-off.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for quick_check also includes type checking, predict the result, then run both on the same disposable database and record duration. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A sound small fixture returns ok. The contrast is explained by this rule: Choose the pragma according to operational needs and document the trade-off. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for quick_check also includes type checking, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain quick_check also includes type checking, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: integrity_check verifies strict column types · Full contents · Next: Other constraints keep their semantics →

CHAPTER 17 OF 20 · Back to contents

17. Other constraints keep their semantics

The short answer: CHECK, FOREIGN KEY, UNIQUE, DEFAULT, COLLATE, generated columns, ON CONFLICT, indexes and AUTOINCREMENT otherwise work as in ordinary tables. The governing rule is: STRICT changes the listed typing rules; it does not invent a new constraint language.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

This makes existing SQLite schema knowledge transferable while keeping the type boundary explicit. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the other constraints keep their semantics example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE s(score INT CHECK(score BETWEEN 0 AND 100)) STRICT;
INSERT INTO s VALUES(101);

Expected result and reasoning. The insert fails the CHECK constraint, independently of the fact that 101 is a valid INT. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Calling every failure a strict-type error prevents accurate diagnosis. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for other constraints keep their semantics
Variable to hold constant: the surrounding setup, so the comparison isolates other constraints keep their semantics.
Variable to change: try text ‘high’ and integer 101 separately
Explanation standard: name the rule, not merely the successful command or copied syntax.

For other constraints keep their semantics, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a homework tracker. Transfer other constraints keep their semantics into a homework tracker. Preserve the governing rule—STRICT changes the listed typing rules; it does not invent a new constraint language.—while identifying what changes in this setting. CHECK, FOREIGN KEY, UNIQUE, DEFAULT, COLLATE, generated columns, ON CONFLICT, indexes and AUTOINCREMENT otherwise work as in ordinary tables. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT changes the listed typing rules; it does not invent a new constraint language.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a small science dataset. Transfer other constraints keep their semantics into a small science dataset. Preserve the governing rule—STRICT changes the listed typing rules; it does not invent a new constraint language.—while identifying what changes in this setting. CHECK, FOREIGN KEY, UNIQUE, DEFAULT, COLLATE, generated columns, ON CONFLICT, indexes and AUTOINCREMENT otherwise work as in ordinary tables. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT changes the listed typing rules; it does not invent a new constraint language.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a migration rehearsal. Transfer other constraints keep their semantics into a migration rehearsal. Preserve the governing rule—STRICT changes the listed typing rules; it does not invent a new constraint language.—while identifying what changes in this setting. CHECK, FOREIGN KEY, UNIQUE, DEFAULT, COLLATE, generated columns, ON CONFLICT, indexes and AUTOINCREMENT otherwise work as in ordinary tables. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT changes the listed typing rules; it does not invent a new constraint language.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a test database. Transfer other constraints keep their semantics into a test database. Preserve the governing rule—STRICT changes the listed typing rules; it does not invent a new constraint language.—while identifying what changes in this setting. CHECK, FOREIGN KEY, UNIQUE, DEFAULT, COLLATE, generated columns, ON CONFLICT, indexes and AUTOINCREMENT otherwise work as in ordinary tables. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “STRICT changes the listed typing rules; it does not invent a new constraint language.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for other constraints keep their semantics, predict the result, then try text ‘high’ and integer 101 separately. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The insert fails the CHECK constraint, independently of the fact that 101 is a valid INT. The contrast is explained by this rule: STRICT changes the listed typing rules; it does not invent a new constraint language. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for other constraints keep their semantics, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain other constraints keep their semantics, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: quick_check also includes type checking · Full contents · Next: Same on-disk format, older-parser boundary →

CHAPTER 18 OF 20 · Back to contents

18. Same on-disk format, older-parser boundary

The short answer: STRICT tables use the same database file format, but older SQLite versions do not recognise the STRICT keyword in schema SQL. The governing rule is: Compatibility depends on reader version even when file pages are structurally familiar.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

SQLite 3.37+ can read and write the schema; older engines can report corruption or schema errors because they cannot parse the table option. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the same on-disk format, older-parser boundary example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

SELECT name, sql FROM sqlite_schema WHERE sql LIKE '%STRICT%';

Expected result and reasoning. The query identifies strict table definitions for a migration inventory. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Saying the file format is unchanged does not promise old software compatibility. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for same on-disk format, older-parser boundary
Variable to hold constant: the surrounding setup, so the comparison isolates same on-disk format, older-parser boundary.
Variable to change: test a copy with the oldest supported runtime
Explanation standard: name the rule, not merely the successful command or copied syntax.

For same on-disk format, older-parser boundary, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a reading log. Transfer same on-disk format, older-parser boundary into a reading log. Preserve the governing rule—Compatibility depends on reader version even when file pages are structurally familiar.—while identifying what changes in this setting. STRICT tables use the same database file format, but older SQLite versions do not recognise the STRICT keyword in schema SQL. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Compatibility depends on reader version even when file pages are structurally familiar.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a family budget prototype. Transfer same on-disk format, older-parser boundary into a family budget prototype. Preserve the governing rule—Compatibility depends on reader version even when file pages are structurally familiar.—while identifying what changes in this setting. STRICT tables use the same database file format, but older SQLite versions do not recognise the STRICT keyword in schema SQL. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Compatibility depends on reader version even when file pages are structurally familiar.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an import validator. Transfer same on-disk format, older-parser boundary into an import validator. Preserve the governing rule—Compatibility depends on reader version even when file pages are structurally familiar.—while identifying what changes in this setting. STRICT tables use the same database file format, but older SQLite versions do not recognise the STRICT keyword in schema SQL. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Compatibility depends on reader version even when file pages are structurally familiar.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an application schema review. Transfer same on-disk format, older-parser boundary into an application schema review. Preserve the governing rule—Compatibility depends on reader version even when file pages are structurally familiar.—while identifying what changes in this setting. STRICT tables use the same database file format, but older SQLite versions do not recognise the STRICT keyword in schema SQL. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Compatibility depends on reader version even when file pages are structurally familiar.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for same on-disk format, older-parser boundary, predict the result, then test a copy with the oldest supported runtime. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The query identifies strict table definitions for a migration inventory. The contrast is explained by this rule: Compatibility depends on reader version even when file pages are structurally familiar. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for same on-disk format, older-parser boundary, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain same on-disk format, older-parser boundary, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Other constraints keep their semantics · Full contents · Next: Migrate with a typed import path →

CHAPTER 19 OF 20 · Back to contents

19. Migrate with a typed import path

The short answer: A migration should reveal rejected rows instead of hiding them. The governing rule is: Create the STRICT destination, copy data in a transaction, classify failures and reconcile them explicitly.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

A direct INSERT SELECT exercises coercion and constraints under the new schema while leaving the source available for comparison. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the migrate with a typed import path example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

BEGIN;
INSERT INTO strict_new(id,qty,code) SELECT id,qty,code FROM old_data;
-- inspect failures; COMMIT only after verification

Expected result and reasoning. Clean rows transfer; incompatible values stop or fail according to the statement and conflict handling chosen. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Casting every value until the insert succeeds can destroy identifiers or conceal bad data. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for migrate with a typed import path
Variable to hold constant: the surrounding setup, so the comparison isolates migrate with a typed import path.
Variable to change: migrate a copied database with one deliberately bad value
Explanation standard: name the rule, not merely the successful command or copied syntax.

For migrate with a typed import path, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a small science dataset. Transfer migrate with a typed import path into a small science dataset. Preserve the governing rule—Create the STRICT destination, copy data in a transaction, classify failures and reconcile them explicitly.—while identifying what changes in this setting. A migration should reveal rejected rows instead of hiding them. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Create the STRICT destination, copy data in a transaction, classify failures and reconcile them explicitly.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a migration rehearsal. Transfer migrate with a typed import path into a migration rehearsal. Preserve the governing rule—Create the STRICT destination, copy data in a transaction, classify failures and reconcile them explicitly.—while identifying what changes in this setting. A migration should reveal rejected rows instead of hiding them. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Create the STRICT destination, copy data in a transaction, classify failures and reconcile them explicitly.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a test database. Transfer migrate with a typed import path into a test database. Preserve the governing rule—Create the STRICT destination, copy data in a transaction, classify failures and reconcile them explicitly.—while identifying what changes in this setting. A migration should reveal rejected rows instead of hiding them. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Create the STRICT destination, copy data in a transaction, classify failures and reconcile them explicitly.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a homework tracker. Transfer migrate with a typed import path into a homework tracker. Preserve the governing rule—Create the STRICT destination, copy data in a transaction, classify failures and reconcile them explicitly.—while identifying what changes in this setting. A migration should reveal rejected rows instead of hiding them. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Create the STRICT destination, copy data in a transaction, classify failures and reconcile them explicitly.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for migrate with a typed import path, predict the result, then migrate a copied database with one deliberately bad value. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Clean rows transfer; incompatible values stop or fail according to the statement and conflict handling chosen. The contrast is explained by this rule: Create the STRICT destination, copy data in a transaction, classify failures and reconcile them explicitly. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for migrate with a typed import path, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain migrate with a typed import path, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Same on-disk format, older-parser boundary · Full contents · Next: Choosing STRICT for the right job →

CHAPTER 20 OF 20 · Back to contents

20. Choosing STRICT for the right job

The short answer: Use STRICT when a table benefits from explicit storage-class enforcement while retaining SQLite features. The governing rule is: Use ordinary tables or specific ANY columns when flexibility is a deliberate domain requirement.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The decision belongs at table and column level and must include version compatibility, nullability, constraints and import behaviour. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the choosing strict for the right job example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

CREATE TABLE readings(
 id INTEGER PRIMARY KEY,
 value REAL NOT NULL,
 source TEXT,
 raw ANY
) STRICT;

Expected result and reasoning. The schema combines enforced numeric readings with an intentionally heterogeneous raw field. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Declaring STRICT as a slogan without testing coercion, keys and clients creates false assurance. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Evidence to collect: the exact input, environment version, observed result and the rule for choosing strict for the right job
Variable to hold constant: the surrounding setup, so the comparison isolates choosing strict for the right job.
Variable to change: write positive, coercible, rejected and NULL test rows
Explanation standard: name the rule, not merely the successful command or copied syntax.

For choosing strict for the right job, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a family budget prototype. Transfer choosing strict for the right job into a family budget prototype. Preserve the governing rule—Use ordinary tables or specific ANY columns when flexibility is a deliberate domain requirement.—while identifying what changes in this setting. Use STRICT when a table benefits from explicit storage-class enforcement while retaining SQLite features. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use ordinary tables or specific ANY columns when flexibility is a deliberate domain requirement.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an import validator. Transfer choosing strict for the right job into an import validator. Preserve the governing rule—Use ordinary tables or specific ANY columns when flexibility is a deliberate domain requirement.—while identifying what changes in this setting. Use STRICT when a table benefits from explicit storage-class enforcement while retaining SQLite features. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use ordinary tables or specific ANY columns when flexibility is a deliberate domain requirement.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an application schema review. Transfer choosing strict for the right job into an application schema review. Preserve the governing rule—Use ordinary tables or specific ANY columns when flexibility is a deliberate domain requirement.—while identifying what changes in this setting. Use STRICT when a table benefits from explicit storage-class enforcement while retaining SQLite features. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use ordinary tables or specific ANY columns when flexibility is a deliberate domain requirement.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a reading log. Transfer choosing strict for the right job into a reading log. Preserve the governing rule—Use ordinary tables or specific ANY columns when flexibility is a deliberate domain requirement.—while identifying what changes in this setting. Use STRICT when a table benefits from explicit storage-class enforcement while retaining SQLite features. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use ordinary tables or specific ANY columns when flexibility is a deliberate domain requirement.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for choosing strict for the right job, predict the result, then write positive, coercible, rejected and NULL test rows. Explain both outcomes without relying on trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The schema combines enforced numeric readings with an intentionally heterogeneous raw field. The contrast is explained by this rule: Use ordinary tables or specific ANY columns when flexibility is a deliberate domain requirement. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for choosing strict for the right job, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain choosing strict for the right job, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Migrate with a typed import path · Full contents · Parent guide →

Parent guide: what mastery looks like

A learner has not mastered SQLite STRICT Tables merely because one polished example runs. Look for four behaviours: they can state the rule in plain language; predict before executing; isolate one changed condition; and explain why a transfer case is the same problem or a different one. Those behaviours make progress visible without requiring a parent to become a specialist.

Use a ten-minute check-in. Ask the learner to choose one chapter, reconstruct its example from memory, and narrate the causal chain. Then change one input. If the learner can update the prediction and justify the change, stop. More repetitions are not automatically better. Save the two-case pair and return to it after a few days.

If every answer is hesitant, reduce the scope. Return to the earliest chapter whose rule cannot be stated accurately. If explanations are fluent but real tasks still fail, move to a capstone because the missing skill is likely transfer or diagnosis. If frustration rises, separate typing errors from conceptual errors and solve only one category in that session.

Capstone practice with explained routes

Capstone 1: Rebuild the smallest trustworthy fixture

Scenario. Create a disposable SQLite fixture that demonstrates table-level strict typing without unrelated project code.

Route. Record environment, input, prediction and output. Keep one nearby contrast. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The fixture succeeds when another learner can reproduce the observation and explain the rule separating the two cases. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 2: Diagnose a believable wrong explanation

Scenario. A learner has the correct output but explains it with the wrong mechanism.

Route. Change the one condition the wrong explanation says matters while holding the real governing condition constant. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The controlled contrast exposes the misconception without turning the task into guesswork. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 3: Handle a version boundary

Scenario. Two environments produce different observations.

Route. Capture versions, platform or browser, exact input and relevant state before comparing. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. A difference is not automatically an error; bind the claim to the documented environment and retest. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 4: Design a parent check-in

Scenario. A parent has ten minutes and no specialist background.

Route. Ask for one rule, one prediction, one run and one changed condition. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The learner demonstrates mastery through a causal explanation and evidence-based revision. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 5: Transfer into a larger project

Scenario. The isolated fixture works but a school or home project does not.

Route. Preserve the fixture, then compare project inputs and dependencies one at a time. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The first dependency that changes the result becomes the next diagnostic focus; the verified rule remains the baseline. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 6: Write a regression check

Scenario. The behaviour must remain understood after an update.

Route. Save the smallest positive case, the near miss and version metadata. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. A useful check reports a meaningful changed observation and points back to the governing rule. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 7: Explain a limitation honestly

Scenario. The selected feature does not cover an important job or is not universally available.

Route. Name the limitation, show what evidence the feature provides and identify the safer route. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Good advice is bounded; it neither discards a useful tool nor stretches it into a guarantee. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 8: Choose the right tool

Scenario. Several related methods or commands appear to solve the same task.

Route. Define desired output, evaluation timing, compatibility and acceptable failure modes. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Select the contract that matches the job and state why at least one tempting alternative was rejected. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Frequently asked questions

Is SQLite STRICT Tables mainly a syntax topic?

No. Syntax is only the handle. Mastery means stating the contract, predicting boundary cases, collecting the right evidence, and choosing a safer or more suitable tool when the contract does not fit.

How long should one practice session be?

Ten to twenty focused minutes is enough for one rule, one worked example, one near miss and one explanation. Stop when the learner can explain the contrast; preserve the fixture for later retrieval.

Should every edge case be memorised?

No. Memorise the central rule and organise edge cases by cause: version, platform, input type, browser support, database schema or repository state. Keep the primary source beside the fixture.

What can a non-specialist parent ask?

Ask for a prediction, the rule behind it, the observation that could disprove it and one changed case. Those questions reveal understanding without requiring the parent to know the command or final value.

When is copying an example useful?

Copying establishes a trusted baseline. It becomes learning after the student predicts the result, reconstructs the example, changes one condition and explains the changed outcome.

How do we separate setup errors from concept errors?

Run a known-good minimal fixture first. If it fails, inspect version, support and transcription. If it passes but the learner predicts a controlled variation incorrectly, the misconception is conceptual.

Should practice start inside a large project?

Not initially. Begin in a disposable directory, tiny script, isolated HTML file or in-memory database. Transfer the verified rule only after the smallest case is understood.

What belongs in revision notes?

Keep the rule in one sentence, the smallest successful example, a near miss, observed output, environment version and one diagnostic question. This is more reusable than copied pages of prose.

What if two computers disagree?

Treat the difference as evidence. Record versions, operating system or browser, exact input and relevant state. Then consult the versioned primary source before deciding that either observation is wrong.

When should the learner move on?

Move on when the learner can explain the rule, predict two contrasts, diagnose a deliberately broken case and transfer the idea to a fresh context without step-by-step prompting.

References and verification notes

Primary technical source: Official SQLite STRICT Tables documentation. SQLite documents the 3.37.0 introduction date, table-by-table syntax, six allowed types, lossless coercion, datatype constraint errors, ANY preservation, primary-key rules, integrity checks and compatibility boundary.

The worked examples were checked with Python’s sqlite3 module linked to SQLite 3.53.1, using an in-memory database; the fixture confirmed numeric-text coercion, datatype rejection, exact ANY preservation, INTEGER versus INT primary-key behaviour and integrity_check ok. The checks confirm the specific examples in this guide; they do not promise identical behaviour on an older version, a different operating system, a different browser implementation, or a repository with different state. Keep the version and environment with the saved fixture.

Last reviewed: 17 October 2026. This article is educational guidance for families and learners. It does not advertise a physical Punggol outlet or make admissions, affiliation, score or outcome guarantees.

eduKate Punggol

eduKate Punggol

Contact

Menu

Email Us

感谢您的回复。 ✨

Small Group Tutorials

How to Master SQLite STRICT Tables in Punggol Tuition

Choose a reading route

1. Flexible typing is the baseline

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

2. STRICT appears after the closing parenthesis

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

3. Strictness is table by table

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

4. The version boundary is 3.37.0

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

5. Every column needs a datatype

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

6. The allowed type names

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

7. Lossless coercion still happens

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

8. Datatype constraint failures

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

9. NULL follows ordinary constraints

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

10. Primary-key columns are implicitly not null

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

11. INTEGER PRIMARY KEY keeps rowid behaviour

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

12. INT PRIMARY KEY is different

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer

Parent and tutor decision point

13. ANY preserves the exact storage class

Worked example: predict before running

Diagnostic route when the answer is wrong

Four transfer cases

Practice, pause point, and explained answer