On this page
Treat the export as a set of related files
In WAL mode, the main database file may contain an older page image while committed changes remain in the write-ahead log. A copy of only main.db can therefore open and answer queries while representing an earlier state. Record the base filename, the presence and byte extent of -wal and -shm, the journal mode observed by an owner-approved read, and the copy method. Never infer a clean checkpoint from a file extension or a successful open.
SQLite explains that readers remember an end mark in the WAL for the duration of a read transaction. That makes the read snapshot a first-class field in the review: identify when the transaction began, whether a writer or checkpoint was active, and whether all related files were copied under a controlled boundary. If that evidence is unavailable, state that snapshot consistency is unverified.
| Evidence | Record | Stop when |
|---|---|---|
| main database | name, byte length, hash, header state | Only a partial copy exists |
| WAL file | present, length, hash, last observed frame | WAL was omitted or changed |
| SHM file | present or intentionally unavailable | The shared-memory state is unexplained |
| journal mode | owner-approved observed value | Mode is guessed from suffix |
| read boundary | transaction start and end mark if known | The reader snapshot is unknown |
| copy method | backup, checkpointed copy, or file copy | Files were copied at unrelated times |
Separate frames, commits, and checkpoints
A WAL contains frames for revised pages and commit markers. A checkpoint transfers committed WAL content back into the main database, but a checkpoint can stop around active readers. Record whether the evidence packet was made before, during, or after a checkpoint and whether the WAL was reset or retained. A smaller WAL is not proof that all expected transactions were included; it may reflect a later state or a new connection boundary.
Use a narrow vocabulary in the report: frame observed, commit boundary observed, checkpoint completed, checkpoint status unknown, or recovery required. Do not turn a page checksum or frame counter into a claim that the application-level export is complete. The SQLite, (opens in a new tab) page describes recovery state and file structure; it does not tell you which business rows a particular owner intended to export.
| State | Evidence question | Report if unanswered |
|---|---|---|
| frame range | Which frames are present and valid? | Frame inventory unavailable |
| commit marker | Where does the last observed transaction commit? | Commit boundary unknown |
| checkpoint | Was all eligible WAL content copied? | Checkpoint completion unknown |
| reader end mark | Which snapshot did the reader use? | Read snapshot unknown |
| recovery | Was a hot WAL recovered? | Recovery history unavailable |
| schema page | Does schema match the intended release? | Schema version unverified |
Review schema and copy timing together
A schema query can succeed against an old main file while the WAL contains a newer migration or index page. Preserve schema evidence with the same snapshot boundary as the data observation: table definitions, indexes, foreign keys if enabled, user-defined objects, and a schema version or migration marker if the source has one. Keep SQL text at structural level and redact values and comments that could expose private records.
Copy timing is its own dimension. A file-level hash only proves that one artifact stayed unchanged after hashing. It does not show that main.db, -wal, and -shm came from one consistent point. Link this review to the relational key guide only after the snapshot is bounded; key counts from mixed snapshots can manufacture or hide orphans.
Questions for the owner-approved export note
- Was the database opened read-only, backed up through SQLite, or copied as files?
- Was WAL mode active when the copy began and when it ended?
- Were all related files kept together under one artifact id?
- Which schema or migration marker belongs to the observed snapshot?
- Were long-lived readers or checkpoints active during capture?
Use a synthetic file-set worksheet
Exercise the worksheet with invented files and frame numbers. The fixture below is intentionally not a WAL parser. It tests whether the packet names the three file roles, a read boundary, a checkpoint statement, and the unknown states that prevent overclaiming. Keep real database values out of the worksheet; a table name and neutral frame marker are enough to test the contract.
Compare the owner note with the file set rather than filling gaps from SQLite defaults. If main.db is present but main.db-wal is missing, the right result is an evidence hold, not a guessed checkpoint. If -shm is unavailable but the copy method is documented as an SQLite backup, record that fact and ask whether the method guarantees a consistent backup for the intended scope.
| Synthetic finding | Disposition | Next evidence |
|---|---|---|
| All three files share capture id | continue conditionally | Confirm read and checkpoint boundary |
| WAL omitted from a WAL-mode copy | hold | Repeat with related files or controlled backup |
| WAL present but hash changed after capture | hold | Reacquire immutable artifact set |
| Schema marker differs from packet note | hold | Resolve migration boundary |
| Checkpoint and reader boundary documented | continue | Run structural relationship checks |
Synthetic WAL export note
artifact: sqlite-fixture-01
files: main.db(hash-a), main.db-wal(hash-b), main.db-shm(hash-c)
mode: wal | read_snapshot: end_mark=12 | checkpoint: not observed
schema_marker: migration-synthetic-4 | values: withheld
disposition: retain as bounded evidence; do not claim complete exportClose with a qualified preparation step
Once the related file set, read boundary, frame and commit evidence, checkpoint state, and schema marker are documented, keep the packet structural. A SQLite consistency review does not reconstruct deleted values, repair corruption, establish ownership, or decide whether a collection can be shared. Use the data provenance log for capture history and keep a data card for scope and exclusions.
For a supported non-health collection, with authority to describe the files and a controlled handling boundary, the qualified appraisal path may be a next preparation step. It does not inspect a database, validate a WAL, create a quote, match a buyer, issue a legal opinion, or grant a license. Keep raw database files out of public worksheets and do not upload them merely to test this checklist.
Takeaways
- Copy main database, WAL, and shared-memory evidence as one bounded set.
- Record the reader end mark and checkpoint state instead of guessing a snapshot.
- Keep schema or migration evidence aligned with the data boundary.
- Use synthetic file sets to test the worksheet before exposing values.
- Run key and orphan checks only after snapshot consistency is established.