DB Browser fixes installer restarts and unintended commits

Installing a database browser should not decide when to restart the computer. The previous DB Browser for SQLite release bundled updated MSVC redistributables that restarted some Windows machines without warning or an opportunity to save files. The 3.10.1 release, announced on 20 September, changes the installer to pass /norestart to that dependency installer.

The release describes itself as a minor bug-fix update for most users, but gives this installation problem particular attention. The behavior came from an included component, yet users encountered it while installing DB Browser. Packaging therefore belongs in the account of what the tool does. Its effects extend beyond the executable that opens a database.

I regard control over consequential operations as part of a database tool's basic usefulness. SQLite gives an application direct access to a database file. A graphical tool built around that file should make it clear when an action affects pending work, whether that action happens during installation or while editing data.

A dependency installer can affect unrelated work

The fix attributed to Mischanix instructs the included redistributable installer not to reboot when it finishes. This is a narrow change to how the outer installer invokes a dependency. It addresses the specific behavior described by the project without requiring a change to SQLite's database engine.

The distinction matters because the failure is outside a normal database interaction. A user need not have opened a database or started a transaction to encounter it. Unsaved work elsewhere on the machine can be affected by a restart initiated during installation. The release's concern is therefore justified even though it does not concern a query result or database format.

The named /norestart option also makes the repair concrete. This is not a general claim that installation has become safer in every respect. The packaging now suppresses a restart by the included runtime installer. The release statement identifies both the component responsible for the earlier behavior and the instruction that changes it.

Editing a column must not commit everything

A separate fix stops table-column editing from automatically committing all changes. The release notes do not provide a full reproduction, so there is no basis for claiming that every kind of edit behaved this way. They do identify the unwanted scope of the action. Editing a column could cause all pending changes to commit.

That behavior crosses an important interaction boundary. The user initiates a particular editing operation, but the tool makes other pending work durable as a consequence. A database editor needs a coherent relationship between the operation presented in its interface and the transaction effects it produces. This fix addresses a mismatch between those two scopes.

The release also repairs index updating when removing an indexed column from a table. A column-removal operation affects schema objects that refer to the column, so the table editor must account for those dependencies. Correctly displaying the revised table definition is only part of the task. The associated index definitions also need consistent treatment.

Custom type saving receives another correction. The notes identify a case where a user-entered type did not save correctly when only the focus changed. This is an interface-state problem with a schema consequence. Moving focus is a normal way to finish entering a value, and the editor must carry the entered value into the saved definition.

I find these fixes more informative when considered as specific editing contracts. They describe the difference between accepting text, changing a schema and committing pending work. A graphical interface brings those operations close together, which makes accidental coupling consequential even when the underlying database engine behaves correctly.

Read-only access still permits inspection

Version 3.10.1 makes text selectable in the Edit dock when a database is open read-only. Preventing writes does not require preventing a user from selecting existing text. The change improves inspection without changing the database's access mode.

The release also adds the <>NULL filter. This gives the data-browsing interface a named way to select non-NULL entries. Filtering is an exploration operation, separate from modifying the values being inspected. Alongside selectable read-only text, it improves the usefulness of the browser when the task is understanding data rather than editing it.

Encryption handling has a fix for passphrases containing single quotes. Such a character is part of the supplied passphrase and must reach the encryption operation correctly. The notes also change the tab order in the encryption dialog. These changes concern input handling in the browser, and do not announce a new encryption algorithm.

Remote database actions become more explicit

The DBHub.io integration receives several repairs. Opening an updated database now asks the user what to do. If the local copy has been deleted, the tool downloads the database again. These changes address the state of the local file and the existence of a newer remote version, which are distinct conditions.

The push dialog enforces name and commit-message length limits. It also supports pushing to branches other than master, and the release fixes its branch list. These details give users more accurate control over the destination and metadata of an upload. Progress and file-size displays for very large files receive corrections as well, so the interface better represents an operation already in progress.

The release joins these remote-workflow fixes with the installer and transaction corrections. Its most consequential changes concern who chooses when something happens. The runtime installer no longer initiates the reported restart, and editing a table column no longer automatically commits all pending changes.