SQLite visualizer: separate preview, type and total

Two displayed rows do not prove the database has two rows, and a BLOB-declared column can contain several storage classes. Read the full count and per-value types separately.

The retained native fixture contains five rows, including NULL, empty text, integer zero, text zero and a two-byte BLOB. A real local SQLite query supplied the captured results. The HTML toggles a two-row preview or all five while keeping the total five visible; it does not open arbitrary uploaded databases.

SQLite visualizer: separate preview, type and total
SQLite visualizer: separate preview, type and total
Open the full example ↗

Work through the example

Select All rows to distinguish integer 0 from text '0' and BLOB hex 0001. Select Preview two to return to two displayed rows without changing the total. Unverified WAL copy clears accepted rows and requests a completed standalone snapshot. Invalid input likewise clears them; neither case silently reuses the previously accepted fixture.

Keep the snapshot acquisition record beside the query results. A preview limit changes display count, not table count. Storage classes belong to values, so a declared BLOB column does not make every cell binary. Hold a live-main-file copy with unknown WAL provenance for a completed standalone backup; readable rows do not establish that the snapshot includes recent commits.

Acquire a completed standalone snapshot

Before opening a file in a later viewer, record its acquisition method, snapshot identity and time, source owner, filename, byte length, and SHA-256 hash. The isolated fixture identity and hash appear in the example; a real input needs its own acquisition record.

A main-file-only copy from a live database is not automatically a complete snapshot. SQLite's WAL documentation explains that the WAL can hold part of the database's persistent state. Readable rows or a familiar header cannot establish that recent committed data was included.

If the live-copy or WAL provenance is unknown, hold the input and request a completed standalone backup from the native owner. SQLite documents completed backup snapshots. The exact native acquisition and completion evidence must be recorded; no backup, checkpoint, deletion, or live database write is performed here.

This one-file inspection requires a standalone snapshot. It does not merge sidecar files, recover transactions or establish that the snapshot reflects the current live system.

Keep freshness separate from integrity. A snapshot can be the intended historical revision without being current, and successful opening alone does not prove all its content is valid.

Define five values that should remain distinguishable

The isolated non-STRICT table samples has id INTEGER PRIMARY KEY and value BLOB. Use these original rows:

id Proposed stored value Expected typeof(value) Intended display
1 NULL null NULL with null badge
2 Empty text text Empty text with text badge
3 Integer 0 integer 0 with integer badge
4 Text '0' text "0" with text badge
5 BLOB x'0001' blob Two bytes; hex 0001

SQLite's datatype documentation describes value storage classes and BLOB affinity without coercion preference. This fixture uses that affinity to preserve the supplied text, integer, null, and blob distinctions. It is not a STRICT-table specification.

The display labels are proposed review conventions. They must not replace the actual values or turn NULL into the literal text “NULL.” Keep the type badge and display representation separate from the underlying result.

An empty text value should not appear as an unexplained blank cell indistinguishable from NULL. Integer 0 and text "0" need distinct type labels even though a casual string conversion could make both look the same.

The blob contains bytes 00 and 01. It is not the four-character text string "0001". The retained native fixture query confirms those five value storage classes.

Pin the engine and keep operations fixed

If you extend this captured-result viewer to open SQLite files, pin the sql.js JavaScript and WASM artifacts and record their underlying SQLite version. Confirm loader compatibility and engine initialization before accepting results from that extension; this example supplies neither a sql.js version nor an initialized loader.

Recreate this example

Build one self-contained responsive HTML example titled “SQLite visualizer: separate preview, type and total” for readers completing the stated task. Return the complete HTML with embedded CSS and JavaScript. Use no remote fonts, libraries, images, requests, account connections, or saved-state claims.

Display captured native SQLite result for isolated non-STRICT samples(id INTEGER PRIMARY KEY,value BLOB):1 NULL/null,2 empty text/text,3 integer0/integer,4 text0/text,5 blob0001/blob two bytes. Native count5. Buttons Preview two, All rows, Unverified WAL copy, Invalid input. Show2of5 or5of5 and storage class beside literal display; no coercion of NULL/empty/zero distinctions. WAL uncertain or invalid case clears rows and holds input. Include actual retained snapshot SHA256 supplied in data. Label captured-query viewer, no arbitrary SQLite/WASM loader or integrity/freshness claim.

Use a type-preserving snapshot inspection desk backed by retained native SQLite fixture results design with a compact header. Keep the actual sample data, controls, and useful default result visible early on a 360px-wide screen. Use readable text at least 16px, generous paragraph spacing, strong contrast, semantic labels, visible keyboard focus, and wrapping source blocks. Stack records on narrow screens rather than forcing a wide table.

Wire each action to an explicit type=button click handler using element selectors; the host permits scripts but blocks form submission. Update the visible result when the described action occurs. Show specific error feedback for invalid or missing input and clear stale feedback after dependent inputs change. Use plain text when displaying user values.

The page inspects captured native fixture results; it does not parse uploaded SQLite files or prove a live snapshot is current. Keep the source fixture and worked teacher or developer example distinct from actual user records. Include the domain-specific explanation and next check beside the result. Provide no fake download, send, deployment, approval, or persistence button. Everything operates locally for the current page session.

Review the prepared copy in NOS

Use the five-value fixture to agree on display labels before inspecting a real authorized snapshot. An HTML explanation in NOS can support visual edits to eligible static type notes. Keep the database bytes, acquisition method and actual query output together in the native inspection record.

Keep reading