navop/docs-site/docs/en-US/guide/sql-editor.md

# SQL editor and transactions

The SQL editor writes, saves, explains, and executes statements. Execution scope, active database, and transaction mode determine the impact. Recheck the connection, schema, and selected text before every production write.

## Create and save queries

Open a query from a database workspace, choose the active database or schema, and enter SQL. Queries can be saved, renamed, and reopened. Auto-save preserves editor content according to Settings, but it neither executes SQL nor replaces version control and backups.

The editor offers smart completion: function signature hints, IN-list and INSERT-clause suggestions, wildcard completion, and cross-database/schema qualified completion with lazy loading. After `FROM`, tables from the active database are suggested; selecting a database continues to suggest qualifier metadata with isolated scopes. Suggestions come from live connection metadata and do not guarantee the object is accessible.

Formatting and compacting change presentation, not correctness. Format settings can preserve keyword case and tune indentation with a live preview; template masking prevents sample code or placeholders from being mangled. Preserve an original copy of complex migrations and validate them in a test database.

## Choose the execution scope

Run selected SQL, the statement under the cursor, or the entire editor. Inspect selection boundaries before running. With no selection, place the cursor inside the intended statement. Run All is suitable only for a fully reviewed multi-statement script, where `@set` variables can pass values between statements, not a scratch file containing examples and temporary DELETE statements.

The result area shows rows, affected counts, or errors. Result tabs can be switched independently and keep scrolling within a stable viewport, even for long or multi-statement results. The maximum-row setting prevents huge previews from exhausting memory. Use export for complete datasets rather than raising the limit without bounds.

## Use EXPLAIN responsibly

EXPLAIN shows plans for supported queries, including scans, indexes, join order, and estimated cost. Syntax and fields vary by database. Variants that include ANALYZE may actually execute the query, so understand side effects and load first.

Keep the original SQL and a baseline. A cost number alone is not enough reason to remove an index or change production logic; data distribution, cache, and concurrency matter.

## Control manual transactions

Automatic mode follows the driver's commit behavior. Manual mode groups multiple writes until you explicitly commit or roll back. Uncommitted work can hold locks and block other sessions.

Before changing database or schema, or closing the editor, Navop asks you to finish a manual transaction. Commit makes the changes durable; rollback discards uncommitted work. After a disconnect, query the server to verify state rather than assuming the transaction outcome.

## Object details and DDL

Hover popups are off by default (enable them in settings; when on they require a 600ms dwell). The right-click "View object details" opens a standalone dialog with selectable, copyable content, and right-click "Copy DDL" copies the CREATE TABLE/VIEW statement of the table under the cursor or selection; selecting a table name and right-clicking resolves it too. Details come from current connection metadata and may lag the server-side definition.

## Recover from errors safely

Reduce syntax, permission, constraint, or timeout errors to one statement and read the server response. Execution errors map to precise source locations, which helps locate the failing statement in a multi-statement script. Do not repeatedly execute while transaction state is unknown. For UPDATE or DELETE, first run the same WHERE clause as SELECT and verify the target rows.

Remove passwords, tokens, personal data, and production literals before sharing saved queries or issue reports.