{{ schema }}
| {{ h }} |
|---|
Download full SQL dump of the database.
SQLite keeps a complete relational database inside a single file. That is convenient for desktop apps, mobile apps, caches, and test fixtures, but it also means the first question is often how to inspect a file quickly without wiring up a separate server or administration stack. This tool opens the file in the browser so you can examine schema, run SQL, and make small changes in place.
That is useful when someone hands you a .sqlite or .db file and you need a concrete answer rather than a full database project. You can see which tables and views exist, inspect the definition behind an object, and query just the rows that matter before exporting the current result set for review.
A typical case is a modest app database with a few thousand rows where you only need the last 100 orders, one customer record, or a quick check that an index or trigger exists. The package keeps that kind of inspection lightweight because the file stays on the device and the first visible row set appears as soon as a query returns data.
It is still a lightweight manager, not a replacement for migrations, concurrency control, backup rotation, or a production-grade administration console. Large files, BLOB-heavy tables, and multi-step write operations deserve a more deliberate workflow than an in-browser grid.
It also helps to separate browsing from editing. A visible grid means the file opened correctly, but it does not guarantee that every object is safely writable or that a text edit preserves the original storage affinity. Treat it as a fast inspection and small-fix tool, then verify any important change with a follow-up query.
For a first pass, load the file through SQLite file, stay in Browse, and pick a table before writing custom SQL. The auto-generated browse query brings back up to 100 rows plus __rowid__, while the Schema accordion shows the stored CREATE statement so you can orient yourself before filtering anything.
This is a good fit for read-heavy exploration, one-off filters, and small corrections to ordinary tables. It is a poor fit for bulk updates, DDL batches, or cases where you need precise typed writes such as NULL, numeric expressions, or function-based updates, because the grid edit path writes cell text as literal string values.
Query for anything more complex than a quick cell fix, then keep the verifying SELECT in History so you can rerun it after changes.No results, do not assume failure. Non-SELECT statements simply do not produce a displayed row set in this package.Export as a file snapshot step, not as an audit trail. The current package saves database bytes with a .sql name.Before sharing or closing the file, rerun a narrow SELECT that shows the changed row and compare it in Browse or Query rather than trusting the temporary highlight from Edit alone.
SQLite stores schema objects and table data in one file, and the tool starts by loading that file into an in-browser database engine. Catalog counts come from the schema table exposed through sqlite_master, with internal names filtered out, so the summary badges reflect only user-facing tables, views, indexes, and triggers.
Choosing an item in Browse does two things. First, the package fetches the stored CREATE statement and shows it under Schema. Second, it builds SELECT *, rowid AS __rowid__ FROM <selectedItem> LIMIT 100; and executes that statement. That is why ordinary rowid tables are immediately browsable, why the first page is capped at 100 rows, and why some objects remain effectively read-only in practice.
The Query tab runs the SQL text exactly as entered after optional formatting. Only the first returned result set is rendered in the grid. If a statement returns no row set, the package clears the grid and shows No results, which is a display rule rather than a transaction report.
Grid editing is intentionally simple. Each changed cell is stored by row and column, then Save assembles UPDATE statements keyed by rowid and commits them inside one transaction. Because the edited value comes from the cell's text content, the saved literal is stringified text. That makes the grid convenient for quick textual corrections, but it is the wrong path for NULL, numeric arithmetic, date functions, or other typed updates.
The package follows a short loop: open the file, inspect the schema catalog, render one result set, optionally queue cell edits, then rerun a query to verify what changed. Query history is stored locally and keeps the most recent unique statements, which makes repeat checks faster but also means those statements remain on the device until removed.
| Output Field | Format/Unit | Meaning | Typical Use |
|---|---|---|---|
Database |
File name | Name of the currently loaded database file. | Confirm you are editing the intended file before running queries. |
Schema |
SQL text | Stored definition for the selected table or view. | Check object type and write expectations before editing. |
__rowid__ |
Integer identifier | Alias used for the row key in the browse query. | Target immediate row updates on ordinary rowid tables. |
No results |
Status text | The executed statement produced no displayed row set. | Signal that you need a follow-up SELECT for verification. |
Save 1, Save 2, and so on |
Pending edit count | Number of queued cell edits waiting to be written. | Verify scope before committing a grid edit batch. |
rowid path.Export action currently writes database bytes to a file named with a .sql extension rather than generating human-readable SQL text.History persists query text locally until you delete entries or clear site data.Use the tool as a short inspect-query-verify loop rather than a full administration session.
SQLite file. When it opens successfully, the Database summary and object badges appear.Browse, choose a table or view, and read the Schema accordion before editing anything. The result grid loads up to 100 rows and adds __rowid__ when the browse query can expose it.Query, write or format a SELECT, and click Run. Rows appear in the grid, or No results appears if nothing is returned.Edit, change the cell, and confirm the button changes to Save 1 or a higher count.Save, then rerun a narrow SELECT in Query or reopen the object in Browse to confirm the stored value. If you need NULL, arithmetic, or function calls, do that in Query instead of the grid.History for repeat verification queries, and treat Export or row-set downloads as a final capture step only after the verifying query returns what you expect.A rerun query that isolates the changed row is the clearest sign that the loaded file now contains the change you intended.
Read the summary counts as a map of what exists in the file, not as a quality score. A database with many tables or triggers is not automatically harder to work with; what matters is whether Schema and the current row set answer the question you came to check.
Schema is the fastest trust check for object type and write path. If it begins with a view definition, treat grid editing cautiously.No results means nothing was rendered, not that the SQL necessarily failed or rolled back. Judge writes with a fresh SELECT.__rowid__ is a convenient update key for the loaded session, not a stable business identifier for reports or downstream integration.The safest verification step is always a new SELECT that isolates the record you changed. If that query returns the expected value and Schema still matches the object you intended to edit, the result is trustworthy enough for lightweight maintenance.
Load staff.sqlite, choose the employees table in Browse, and open Schema to confirm you are looking at the right object. The grid query returns the first 100 rows plus __rowid__. Switch to Edit, change one status cell from probation to active, and confirm the button shows Save 1. After saving, run SELECT rowid, status FROM employees WHERE rowid = 17; in Query. That is the right pattern for a small textual correction that needs explicit verification.
Load sales.sqlite and choose recent_orders from the object list. Schema now shows a CREATE VIEW statement, and the grid can still display returned rows for inspection. Treat that as a read-focused path: inspect the returned columns, export the current result set if needed, and avoid assuming the view is safely editable through the grid just because rows are visible.
No results appears after a writeIn Query, run UPDATE customers SET tier = 'gold' WHERE id = 9;. The grid clears and No results appears because the statement returned no displayed row set. Follow it immediately with SELECT id, tier FROM customers WHERE id = 9;. If the new row shows gold, the write succeeded and the earlier status line was simply reflecting the package's display rule.
The file is opened and queried in the browser. The package does not send the database to a server, but it does keep query history locally until you delete it or clear site data.
No. Tables and views are both listed, but dependable grid edits require an updatable object and a usable __rowid__ path. Some selections are best treated as read-only.
No results appear after UPDATE or DELETE?Because the package only renders returned row sets. Statements that change data without returning rows clear the grid and show No results until you run a verifying SELECT.
Grid edits are taken from the cell text and written back as stringified text. Use Query when you need NULL, numeric math, functions, or other typed SQL expressions.
Export a true SQL dump?Not in the current package behavior. The download is produced from the database bytes and named with a .sql extension, so treat it as a file snapshot rather than rendered SQL text.