Now runs on macOS 14 SQLiteEasy asked for macOS 15.6 and did not need it. It runs on macOS 14 and later from this version, so it installs on Macs it previously refused. Safer opening of databases that are in use SQLiteEasy now reads a database's journal mode before opening it rather than after an attempt fails, and picks the one approach that is correct for that mode. Two things follow: - A database in write-ahead-log mode with no active log is opened without creating a sidecar file next to it. - A database with an unfinished transaction in its rollback journal is reported plainly, rather than being opened in a way that could show uncommitted rows as though they were committed. The second is the one that mattered. Replaying such a journal needs write access, and the read-only shortcut that avoids it can return rows that were never committed while an integrity check still reports the file as fine. SQLiteEasy would rather tell you it cannot answer. Rate SQLiteEasy A new item in the Help menu, if you would like to leave a review. Nothing is gated behind it and nothing nags: the app asks at most once a season, and only after several separate days on which something worked.

Compare Databases See exactly what changed between two SQLite databases — press Shift-Command-D, use the new toolbar button, or open it from the View menu. SCHEMA - Tables, columns, indexes, triggers, views and foreign keys, compared by what they mean rather than by their text. Reformatting a CREATE statement, changing keyword case or adding a comment is not a schema change, and is not reported as one. - Every change is named in words, and where a change is a loss the words say so: "Column dropped - its values go with it", "Index dropped - some queries may slow down". - Changed values sit side by side, labelled with the two file names, so an empty pane means the object is not in that database. - A column added in the middle of a table is one added column and one order change, not a change to every column after it. - Constraints no PRAGMA reports - CHECK, ON CONFLICT, generated columns - are compared through the table's definition, so they cannot go unnoticed. ROWS - Which rows were added, removed or changed in every table the two databases share, and for a changed row, only the columns that actually moved. - Rows are matched on a primary key or a unique index, never on SQLite's internal rowid, which does not survive VACUUM or a dump and restore. - The key is checked against the data before it is trusted. SQLite does not enforce NOT NULL on a rowid table's primary key, so a declared key is a candidate, not a guarantee. - A table that cannot be compared honestly says so and says why - no key to match on, or a COLLATE clause that changed what counts as the same value - and still reports its row counts. - NULL, an empty string and an empty blob stay three different values, in the comparison and on screen. SNAPSHOTS - Save a database's schema to a file and compare against it later, without the original database. Useful next to your migrations in version control. - A snapshot holds the schema only. No table contents, and the database's name but never its path. Neither database is ever written to. The comparison opens both read-only.

One new feature Schema Map. A diagram of every table and the foreign keys between them, in its own window. Reachable four ways (⇧⌘M, toolbar button, View menu, right-click a table). Three detail levels, zoom, fit-to-window, click-through to browse a table, PNG export. The correctness details it gets right, which is the part competitors are sloppy about: - A composite key draws as one relationship, not one per column - REFERENCES authors with no column list resolves to the parent's primary key - REFERENCES BOOKS matches books — SQLite is case-insensitive, so a case-sensitive lookup would invent a broken edge - A self-reference draws as a loop - A foreign key pointing at a table that no longer exists is flagged, not dropped — legal in SQLite, real in any database that's had a table removed