Database (SQL console)

The Database section turns Context Code into a full multi-engine client: an SSMS-style object explorer, a tabbed script editor, ER diagrams, history, backups and an AI assistant that understands your schema.

Supported engines

PostgreSQL, MySQL / MariaDB, SQLite, SQL Server, Oracle and MongoDB.

Connecting a database

1. Open Database in the top capsule (or Open SQL Console) and press New connection.
2. Pick the Engine and fill in the details: server/host, port, user, password and database; the file path (.db / .sqlite) if it’s SQLite; Service name / SID if it’s Oracle. For servers with TLS there’s SSL mode (MySQL and PostgreSQL) and “Trust server certificate” (SQL Server).
3. Test connection confirms the details are right; Save connection keeps it in your Saved connections.

Each script tab remembers its own connection (Ctrl+Shift+S) and its own database (Ctrl+Shift+D).

The console: object explorer on the left, script and results on the right.

Your session survives switching sections

You can go to the chat, the editor or Developer mode and come back: the console is exactly as you left it — the active connection and database, the explorer tree already expanded, your script tabs (which also survive an app restart), the cursor, the scroll and the undo history of every script.

When you come back, the app quietly checks the connection and, if the server had closed it, reconnects on its own without telling you.

Note

The new connection does not inherit the USE or the temporary tables of the previous one: if your script depended on a #temp table, create it again.

Connections that don’t drop

For SQL Server and Oracle there’s a heartbeat every two minutes that keeps the session alive. And if a run fails because of a connection error (the network dropped, the server restarted), the app reopens it and retries exactly once. SQL errors — a misspelled column, a violated constraint — are not retried: repeating an INSERT blindly would be worse than the error.

Running scripts and batches

• F5 or ▶ runs the whole script, or only what you have selected; Ctrl+Enter runs the statement under the cursor.
• The script is sent statement by statement, so you get a results panel for every SELECT and can move between them.
• If something fails, the message places you: “Batch 3/7 (script line 42)”.

Batch separators per engine

Engine	Separator	Detail
SQL Server	GO	Only counts when it’s on its own line. Accepts GO 5 to repeat the batch 5 times and a -- comment after it. It never splits anything inside strings, identifiers or comments.
Oracle	/	On its own line.
PostgreSQL, MySQL/MariaDB, SQLite, MongoDB	—	No batch separator.

Every batch goes over the same connection, so USE, temporary tables and transactions carry over from one batch to the next.

Scripts that touch several databases

• SQL Server: the console prepends the USE [database] from the selector and accepts three-part names (database.schema.table). If the script names a database other than the context’s, it warns you — “The script names database X but the context is Y” — and offers Rewrite to Y or Remove database prefixes.
• PostgreSQL: opens a temporary connection for every database the script needs.
• MySQL: you have to qualify with database.table.

Browsing the schema

The Object Explorer is a single SSMS-style tree: Databases, Diagrams, Tables (including system, external and graph tables), Views, Synonyms, Programmability (Procedures, Functions), Query Store, Service Broker, Storage, Security, and inside each table its Columns, Indexes and Statistics. It has a filter, expand/collapse all, refresh and copy connection string.

The context menu brings the usual shortcuts: query the top 100 rows, generate INSERT / UPDATE / DELETE, create or drop a database, create a table, open the ER Diagram or the Data Model, copy the name (simple or qualified), run USE, open a new query here, back up, restore and generate scripts.

Results

Results and Messages tabs, with rows returned or affected and the execution time. Ctrl+R hides or shows the panel.

A long script opens a Resultado N tab (the label is the same in every language) for every query that returns rows. Context statements — USE, SET, DECLARE — don’t open a tab: they used to clutter the panel with empty results you had to skip past. Every tab has its X to close it, and there’s “Close all results” to clear the panel in one go.

Selecting rows and copying them

The grid works like a spreadsheet:

To	Do
Select a row	Click it
Add or remove individual rows	Ctrl + click
Select a range	Shift + click
Select everything	The header checkbox, or Ctrl+A
Clear the selection	Esc

Ctrl+C copies as TSV, which is what Excel and Google Sheets paste into columns without asking anything.

The context menu gives you the other ways to get the data out:

• Copy row(s) and Copy with headers
• Copy as CSV
• Copy as INSERT — it asks you for the target table name
• Copy cell
• Select all and Clear selection
• One setting: “Copy NULL as the text “NULL””, for when the destination can’t tell a null from an empty cell

Caution

If the result came trimmed (“there are more rows than the ones shown”), when copying it warns you that only the rows shown go out and offers Export CSV, which does get the full set. Copying blindly from a trimmed result is the easiest way to produce half a report without noticing.

Double-click still edits the cell, as always.

Every query you run is kept in the history, which persists across sessions.

ER diagrams

Entity-relationship diagrams with three automatic layouts — grid, hierarchical and radial —, keys-only view, grid snapping, manual rearranging and zoom. You can keep several diagrams per database: add tables, rename them, duplicate them, delete them and save them; they’re stored in the app’s local database.

The AI assistant

Ctrl+I opens the assistant inside the console. It knows which connection and which database you have in front of you, and can explain a query, optimize it, convert it to another dialect or detect errors; the result is applied to the script or inserted at the cursor.

It also knows how to work in a loop — generate, run, fix — up to eight attempts. What it may do without asking you is up to you in Agent permissions (right below): it tells reads from writes and from destructive operations, and warns when something looks irreversible or when the connection looks like production.

Backups, restore and scripts

Each engine with its own tools: BACKUP / RESTORE on SQL Server, pg_dump / pg_restore on PostgreSQL, mysqldump on MySQL, VACUUM INTO on SQLite, mongodump on MongoDB and expdp / impdp on Oracle. Script generation supports DROP IF EXISTS, indexes, foreign keys and how many rows per INSERT, and writes the result to a new tab or to a file.

Agent permissions, per connection

You decide what the assistant may do on each database. In the header of the connection’s chat there is an Agent permissions for this connection button with a summary of what is in force; when you open it you’ll see:

What the assistant may do on “your connection”. Anything switched off is refused before touching the database.

That sentence is literal: what is denied never reaches the database. It is not a warning, it is a brake.

The three presets

Preset	What it allows
Read only	The factory default. Read data and view the schema, nothing else. Every write would ask for confirmation.
Development	Also writes, deletes, creates and alters objects, runs routines, transactions and exports. It does not drop objects (DROP). Tolerates up to 100 affected rows without asking.
Administrator	Everything, including DROP, with a cap of 1000 rows without asking.

If you flip a single switch, the preset becomes Custom.

The switches

Switch	What it covers
Read data (SELECT)	Queries that return rows.
View schema	Tables, columns and relationships.
Write data (INSERT/UPDATE)	Adds or changes rows.
Delete data (DELETE/TRUNCATE)	Removes rows from tables.
Change schema (CREATE/ALTER)	Creates or alters objects.
Drop objects (DROP)	Irreversible: destroys whole tables.
Run procedures and functions	EXEC, CALL and stored blocks.
Transactions	BEGIN, COMMIT, ROLLBACK, SAVEPOINT.
Auto-commit	If off, every COMMIT is confirmed.
Export to file	Writes results or copies to disk (INTO OUTFILE, COPY … TO, BACKUP).
Ask before every write	Nothing runs without your approval.

And one number: Maximum affected rows without confirmation (0 = always ask).

Permissions are stored per connection, inside the application’s own encrypted database. If you haven’t saved the connection, they’re remembered by engine and label.

What the assistant does with them

Before every schema read, data sample or execution, the assistant checks the permissions:

• What is denied isn’t even attempted, and the model explains it to you instead of failing blindly: “I don’t have permission to delete on this connection; enable it in Agent permissions”.
• What requires confirmation tells you why and, when it can be measured, how many rows it’s going to touch.
• If you edit the SQL in the confirmation dialog, the text that remains is validated again, not the original.
• What is irreversible is always confirmed, even if the permission is granted.
• A mixed script is denied as a whole if a single one of its statements is forbidden: it doesn’t run “as far as it gets”.

Classification is per engine — PostgreSQL, MySQL/MariaDB, SQL Server (with GO), SQLite, Oracle (with /) and MongoDB — and ignores strings, comments and quoted identifiers, so a DELETE inside a literal doesn’t count. It also recognizes the usual disguises: WITH … DELETE, SELECT … INTO, MERGE and the body of a procedure.

Two limits worth knowing

The export buttons of the results grid (CSV, JSON) don’t go through these permissions: they’re yours, not the agent’s. And the row estimate is only computed for simple UPDATE and DELETE; for the rest you’ll see the reason for the confirmation, but not a number.

Tip

For a production database, two belts are better than one: leave the preset on Read only and also connect with a database user that can’t write either.