Start Pro Trial

VisuaLeaf v1.0.2264 Release Notes

August 28, 2026

VisuaLeaf v1.0.2264 Release Notes

Release Date: August 30, 2026


Headline: Query Builders That Take the Whole Window, Oracle and SQL Server Addressed the Way Your DBA Wrote Them Down, Shell Scripts That Keep Running, Fixed Query Field Deletion

  • Both query builders open into the full workspace β€” and the SQL one becomes a real ERD canvas you can drag, pan and zoom, with your tables as cards and the generated SQL beside them.
  • Connection modes for Oracle, SQL Server and any engine you'd rather address yourself. An Oracle database that answers to a SID could not be connected to at all before this release. Neither could a SQL Server named instance.
  • Two bugs that were costing people real work are gone: switching tabs mid-script no longer loses the run's output and results, and the MongoDB query field no longer deletes the last second of what you typed.

Alongside those: a row editor that holds your work when the database says no, foreign keys that finally appear on DuckDB, table metadata that stops mixing up same-named tables in different schemas, and a rebuilt naming pass for Generate Mock Data β€” including credit-card, IBAN and BIC values that pass a validator.


Query Builders, Full Screen

Both the MongoDB and SQL builders now expand out of their side panel and take the whole workspace β€” one button, and the panel slides into its new shape rather than jumping there.

What you can see

  • The SQL builder becomes an ERD. Your tables are cards on a canvas with their joins drawn between them, instead of a stack in a narrow column. Drag a card to move it, drag the canvas to pan, scroll to zoom, or hit Tidy to lay everything out again.
  • The generated SQL sits alongside the canvas, with a Copy button β€” so you can see the query taking shape as you build it.
  • The MongoDB builder gets the same room, with zoom and "fit the query in view" controls, and your condition groups laid out as nodes rather than nested boxes.
  • An empty canvas says what to do β€” "No tables yet Β· Add one to start building the query" β€” instead of showing nothing.

What you can do

  • Search for a table to join from the canvas itself, without collapsing back to the sidebar.
  • Collapse back at any time β€” the builder returns to the side panel with everything exactly as you left it.
  • Copy the query from either builder in one click.

Connecting to Oracle and SQL Server, Properly

VisuaLeaf could only ever address Oracle one way: as a service name. A database that answers to a SID was unreachable, and so was a SQL Server named instance. Both are now first-class, alongside a mode for typing your own JDBC URL.

| Engine | Modes |
|---|---|
| Oracle | Service Name (default), SID, TNS Alias, TNS Descriptor |
| SQL Server | Port (default), Named Instance |
| Every host-based engine | Custom JDBC URL |

  • The form reshapes itself to the mode. Host and port disappear for a mode whose address already names its server; the port alone disappears for a named instance, which replaces it. The Database field is relabelled Service Name or SID β€” calling a SID "Database" is exactly how a service name ends up typed into it.
  • TNS Alias and TNS Descriptor connect through your existing tnsnames.ora or a descriptor pasted straight in.
  • Copy link now exports the URL your connection actually uses. A SID connection used to export the service-name form β€” the precise URL that comes back as ORA-12514.
  • When a save is refused, you get the reason. The server rejects several things you can act on β€” a password embedded in a custom URL, a URL whose scheme belongs to a different engine, a malformed instance name, an SSH tunnel a mode can't route through β€” and each is written as a sentence telling you what to do instead. Those sentences used to be thrown away and replaced with "400 Bad Request".
  • The default port follows the engine again. After switching engines once, it used to stay on the previous engine's port for the rest of the session.
  • Custom URLs are not offered for SQLite and DuckDB, deliberately β€” those two are confined to a configured folder on the server, and a hand-written URL would walk straight around it.

Existing connections are untouched: a connection saved before this release dials exactly the URL it always did.


A Long Script No Longer Loses Its Results Because You Looked Away

This is the big one. Start a script that takes a few minutes, switch to another tab while it works, and everything it produced after you left was gone: no output, no result tabs, and a console that came back empty. The script itself carried on running on the server β€” the app simply stopped listening to it, so the only way to see a long run through was to sit and watch it.

  • Output keeps arriving while you're on another tab, and it's all there when you return.
  • Results appear for work finished in your absence β€” result tabs are now built whether or not you're looking at the shell.
  • The console keeps its history across tab switches, rather than starting from empty, and holds a long run's worth of lines.
  • Nothing is lost by closing and reopening the shell tab either; the run and its output belong to the shell, not to whether it happens to be on screen.

The Query Field Stops Deleting What You Type

The other one worth naming. Typing a query into the MongoDB query field, you could watch characters vanish about a second after you paused β€” most reliably by typing {}, then a quote, and seeing the quote disappear.

The field and the visual query builder keep each other in step, and the builder was answering with a snapshot of what the field held roughly a second earlier. Anything typed in the meantime was overwritten by it. The longer you thought between keystrokes, the more reliably it bit.

  • Whatever you type stays typed. The builder no longer echoes stale text back over the field.
  • Edits made in the builder still flow to the field, exactly as before β€” only the echo of your own typing is dropped.
  • Applies to the query, sort and projection fields alike.

Tables, Schemas and Foreign Keys

A set of fixes for things the app reported confidently and wrongly on engines where one database holds many schemas.

  • Two tables with the same name in different schemas no longer merge. Opening customers on a database that has one in main and another in retail produced a card with six columns for a three-column table, mixing both. This ran through the table card, "add this table" on a diagram, the query builder, the row editor, the foreign-key preview and the table context the AI reads.
  • Table statistics answer about the schema you asked for. A blank schema didn't mean "the default one" β€” it meant no filter at all, so the numbers covered every schema at once.
  • DuckDB foreign keys exist and are now visible. The driver refuses the question outright, and the refusal was being read as "this table has no foreign keys": Foreign Keys (0) in the connection tree, an empty Foreign Keys section, no relationship lines on a schema diagram, and "Relinked 0 foreign key(s)" from a button you pressed precisely because the keys are there. They're now read from DuckDB's own catalogue.
  • CrateDB tables no longer come back with no columns. A single unsupported metadata call was closing the pooled connection underneath, and everything after it failed silently β€” a table with columns and a table the app couldn't read looked identical.
  • Oracle table statistics are collected properly rather than falling back to a generic read.
  • The system monitor says what failed. An Oracle error arrived as a bare ORA-00942: table or view does not exist with no indication of which operation produced it.

Inserting and Editing Rows

  • The dialog stays open when the database refuses the write. It used to close first and report the failure as a toast afterwards β€” so your entire typed row was gone by the time you read why. Now the values survive, the offending column is marked with the driver's own reason, and the fix is one keystroke.
  • Insert & add another β€” commit the row and keep the dialog open for the next one.
  • Numeric fields check themselves as you type, per column type, instead of failing at the server.
  • Duplicate-key and foreign-key failures are written in plain language across MySQL/MariaDB, PostgreSQL, SQLite and SQL Server, and a duplicate spells out which values clashed. SQLite's referential errors are the awkward ones β€” they name the other table in the broken link β€” so they now say which table you're actually unable to write.

Generate Mock Data: Better Guesses From Column Names

  • A column called exactly name used to produce random text. Every person rule was anchored to a compound β€” first_name, full_name, company_name β€” and the plain case was never written. It now maps to a full name, without stealing the compounds' own generators.
  • Naming rules went from 33 to 54, reaching generators that inference could never previously select: credit card, IBAN and BIC β€” these carry real checksum structure, so anything validating the value accepts the generated rows β€” plus salutation, gender, nationality, occupation, tagline, material, promo code, barcode, ticker, currency name, password, file extension, checksum, colour hex, word and paragraph.

Fixes Worth Naming

  • Opening a saved query containing a regular expression broke the query builder. Patterns written in any of the three spellings the app itself produces are now all understood.
  • The advanced driver properties panel sat flush against the footer, reading as one crowded line.

Notes

  • TNS Alias mode reads tnsnames.ora from the machine running VisuaLeaf, not from the database server β€” point the mode at the folder holding that file.
  • Custom JDBC URLs must use the scheme of the engine you selected, and may not carry a username or password. The URL is stored as typed and shown again on every read, unlike the password field, so credentials belong in their own boxes.

See the full release history