SQLlyCompetitor watch: the tree that keeps up
Twelve schema-tree and metadata reports checked against SQLly: a CREATE TABLE refresh gap fixed, a SQLite bug found and fixed, column filter and schema hiding built.
Today's batch is the schema tree and the metadata hanging off it: comments that are fetched and never shown, types and triggers that want a folder, schemas that won't stay hidden, and a new table that refuses to appear until you restart the app. Twelve reports across Beekeeper Studio, DbGate, DBeaver, HeidiSQL and Sequel Ace. SQLly already had six of them, was safe from three, built two today, and had one for real: our explorer also ignored a CREATE TABLE you ran yourself, until this afternoon. Chasing that one turned up a SQLite bug of our own, which we fixed too.
Refreshing and reloading does not work properly when creating a table using a query/sql — DbGate
Opened 4 months, 3 days ago; last vendor reply 2 months, 16 days ago. Zero reactions and two comments. KanchiMoe ran a CREATE TABLE on PostgreSQL and found the new table missing until DbGate was relaunched. Stela Augustinova suggested refreshing the database structure, which works, and KanchiMoe made the fair point that it would be nice if it happened on its own, the way it already does when a table is dropped. We tried it in SQLly and were in no position to tease: our tree also waited for a manual refresh. It doesn't any more. Any CREATE, ALTER, DROP or RENAME in a run now refreshes the explorer and IntelliSense, keeps your expanded nodes, and updates an open table's columns after ADD or DROP COLUMN. Fixed today.
SQLite: a TEMP table named pragma_table_list breaks all metadata loading — DBeaver
Opened 16 days ago and closed as fixed 11 days later, which is brisk by anyone's standards. Zero reactions and zero comments. Marco Alejandro De Santis traced it to the line: a TEMP table named like SQLite's built-in pragma function shadows it, and every metadata query after that fails until you reconnect. SQLly's metadata queries used the same bare names, so we checked properly. SQLly reads metadata on its own connection, so a TEMP table from your editor can't get in the way. We spelled the pragma functions out in full anyway and added a test that sets every one of them a decoy. Looking hard at SQLite also turned up a bug that really was ours: on a SQLite connection the explorer's main node opened an empty file called "main" instead of your database, so we fixed that as well. Checked, not affected.
table->Structure->filter, support comment — Sequel Ace
Opened 1 year, 3 months ago; last vendor reply the same day. Zero reactions and two comments. superadmini asked for the Structure view's filter to match column comments. Jason Morcos asked for more detail, got a screen recording within minutes, and the thread has been quiet for fifteen months since, labelled Low priority. SQLly's structure editor had no column filter at all, so we built one that matches name, type and description. Built today.
Schema filtering / sticky schema hiding in the sidebar — Beekeeper Studio
Opened 1 month, 2 days ago; no vendor reply, though the vendor wrote it, so that's fine. Zero reactions and zero comments. Matthew Rathbone passed on a request from a Reddit user whose database has more schemas than anyone wants to scroll past, and noted that hiding them today doesn't stick. SQLly could hide system schemas globally, but not your own schemas per connection. Now it can, and they stay hidden after a restart. Built today.
UX: Table description/comment is fetched but never displayed in the UI — Beekeeper Studio
Opened 1 month, 24 days ago; no vendor reply, ever. Zero reactions and zero comments. Jean Carlos Paiva Miranda wrote the kind of issue maintainers dream of: the backend already fetches the table description and can even save it, and only the UI is missing. SQLly shows and edits the table description in Edit Structure and in the table's Properties, on SQL Server, PostgreSQL, MySQL/MariaDB, Oracle, DuckDB and ClickHouse. Already have it.
PostgreSQL table structure doesn't show table descriptions or column comments — DbGate
Opened 6 months, 12 days ago; no vendor reply, ever. Zero reactions and one comment. 樊宇澄 asked for it in one sentence, and KanchiMoe kindly translated it six weeks later, which is more attention than the vendor has given it. SQLly reads PostgreSQL table and column comments and shows them in the structure editor and Properties. Already have it.
postgres columns COMMENT or table COMMENT Not displayed — DbGate
Opened 1 year, 28 days ago; no vendor reply, ever. Three reactions and one comment. csap reported the same gap six months earlier and posted a screenshot of another tool doing it, the gentlest form of shade. Two issues, one request, no reply on either. Same answer as above: SQLly shows them. Already have it.
Wrong table comments encoding in SQLSRV — DbGate
Opened 1 year, 21 days ago; no vendor reply, ever. Zero reactions and one comment. diverdm showed SQL Server table comments rendered as mojibake, then came back seven months later to report that the bug is still here. SQLly converts SQL Server's MS_Description values to Unicode text on the server before reading them, so non-Latin descriptions arrive intact. Checked, not affected.
Show defined data types in PostgreSQL schemas — DbGate
Opened 2 months, 17 days ago; no vendor reply, ever. Zero reactions and zero comments. AkibaWolf wanted a Types section next to Tables, Views, Functions and Triggers so enum and composite types are easy to find. SQLly's explorer has had a Types folder under each PostgreSQL schema's Programmability for a while, listing enum, composite and domain types. Already have it.
Show triggers in table editor — HeidiSQL
Opened 10 months, 21 days ago; last vendor reply 8 months, 8 days ago. Zero reactions and two comments. yanis60 was tired of querying information_schema.triggers to see what fires on a table. Ansgar Becker agreed it was reasonable but worried the table editor was already crowded, then sketched a new Triggers tab. A thoughtful reply, and still a plan rather than a feature. SQLly lists each table's triggers in a Triggers folder under the table and on the table's Properties page. Already have it.
When I change the schema, most of the time the "TABLE, VIEWS, FUNCTIONS" pane breaks down — DbGate
Opened 4 months, 4 days ago; no vendor reply, ever. Zero reactions and zero comments. Sabudh Thapa found that switching schemas broke the object pane four times out of ten, more often with several connections open in different tabs. Four out of ten is about as flaky as it gets. In SQLly every load in the tree is stamped, and a late answer from an earlier load is thrown away instead of drawn over the fresh one. Tests cover exactly that race. Checked, not affected.
Over 30,000 tables, DbGate becomes very slow when reading table structures — DbGate
Opened 1 year, 12 days ago; no vendor reply, ever. Three reactions and zero comments. hzpemu wrote a kind, well-argued suggestion: list the table names first and load a table's structure only when you open it. Three thumbs-up, and a year of nobody saying anything. SQLly's explorer already works that way, loading table names when you open the Tables folder and a table's columns when you expand it. Checked, not affected.