SQLlyCompetitor watch: the editor that guesses wrong
Twelve open issues from DBeaver, DataGrip, HeidiSQL, Sequel Ace, DbGate and Beekeeper on parameters, script splitting and autocomplete, checked against SQLly.
This morning was about getting into the database. This afternoon I read twelve more open issues from six other SQL clients, all about what happens once you start typing: parameters nobody declared, scripts split in the wrong place, and autocomplete that guesses wrong. I checked every one against SQLly.
SQLly had three of them, and all three are fixed today and ship in the next release (changelog). Checking a fourth turned up a quieter bug of our own, also fixed. The other nine SQLly doesn't have, or already does what was asked.
This is the daily competitor watch, part two for October 20. I take a batch of open issues from other SQL clients' public trackers, check whether SQLly has the same problem, and fix it if it does. The people who reported these did the hard part, so every one of them is named and linked below.
Score: SQLly had three of these, now fixed. Accepting a suggestion inside a backticked name left the old name's tail behind, exactly as Sequel Ace's video shows. Typing beg at the start of a statement offered nothing, and a half-typed @us ranked itself above the @user_name it should have completed to. And running DBeaver's reporter's own CTE query showed that SQLly didn't know a CTE's columns at all. That's a different cause from DBeaver's bug, but it's the same bad result, so we fixed it. While checking the parameter issues we also found and fixed a quieter bug: a declared parameter inside a PostgreSQL array slice (arr[@lo:@hi]) was never filled in. The other nine we checked: they aren't problems we have, or SQLly already does what's asked. Results land in the SQLly changelog with the next release.
Ages are as of October 20, 2026. "Vendor" means someone the tracker marks as a member, collaborator or staff. For the YouTrack issues we report votes and comments only, since the tracker doesn't show us who is staff.
Parameters that nobody declared
Bind Parameters dialog triggered by ${timestamp} inside SQL comments (affects @export directives) DBeaver #42360
Age: opened 11 days ago (October 9, 2026). No vendor reply yet.
Reactions / comments: 0 / 2.
The vibe: the reporter commented out an export directive to switch it off, and DBeaver still asked them for a timestamp. A comment that still gets read isn't much of a comment. A first reply couldn't reproduce it. Eleven days later another user did reproduce it, in a unit test, and offered to fix it.
Credit: @btanner2 reported it with a clear Git-versioned-scripts use case. @davestokes replied that he couldn't recreate it yet. @Rishavbhattarai reproduced it in a unit test and volunteered a fix.
SQLly: checked, not a problem we have. SQLly only asks for values you declare with a -- sqlly param: line, and never reads placeholders out of comments. A guard test now pins that.
User parameters popup for PostgreSQL array slice syntax DataGrip DBE-25057
Age: opened 10 months ago (December 21, 2025). Unresolved.
Votes / comments: 2 / 2.
The vibe: my_array[min_bound:max_bound] is perfectly ordinary PostgreSQL, and DataGrip reads :max_bound as a parameter. The workarounds people traded say a lot: type :max_bound into the popup as its own value, or wrap the bounds in parentheses.
Credit: reported by Umair M. on the tracker. lee.urnh added the type-it-back-in workaround, and Alex Bolenok (quassnoi) the parentheses one.
SQLly: checked, not a problem we have: a colon is never a parameter. But checking it turned up a cousin. If you declared @lo and @hi and wrote arr[@lo:@hi], SQLly treated the brackets as a SQL Server quoted name and left the values out. That's fixed now. On PostgreSQL, DuckDB and every engine that doesn't quote names with brackets, values go into array slices.
Impossible to disable user parameters for queries with a colon ":" for Databricks syntax DataGrip DBE-18646
Age: opened 3 years, 2 months ago (August 8, 2023). Unresolved.
Votes / comments: 6 / 2.
The vibe: you untick every parameter pattern in Settings, and the popup comes anyway. A user checked in two years later to confirm it was "still an issue in the latest versions". It's old enough now to start kindergarten.
Credit: reported by Arina Efremova. Brandon Schow (Brandon_Schow) and lee.urnh confirmed it was still happening.
SQLly: checked, not a problem we have. metadata:country runs as written on every engine, because a colon is never a parameter in SQLly.
Allow running queries without user parameter substitution DataGrip DBE-27337
Age: opened 2 weeks ago (October 6, 2026). Unresolved.
Votes / comments: 2 / 0.
The vibe: the tidy summary of the two above: switch it all off and the dialog still opens, so please give us an "Execute as is". Three tickets, one wish.
Credit: reported by Anastasia Zhukova, linking back to DBE-25057.
SQLly: already have. A query with no -- sqlly param: or -- sqlly set line is sent exactly as written. There's nothing to switch off.
QUESTION: In SqlServer why is asking me to provide parameters if I only want to execute a query without parameters Beekeeper Studio #4702
Age: opened 7 weeks ago (August 28, 2026). Last vendor reply 7 weeks ago. Labelled need-more-info.
Reactions / comments: 0 / 2.
The vibe: a plain join with a commented-out WHERE, and a parameter prompt. A contributor couldn't replicate it. The reporter answered within hours, with a screenshot of the exact selection and button. Then nothing for seven weeks, and the need-more-info label stayed on.
Credit: @dmacchiavello reported it and followed up the same day. @azmy60 tried to reproduce it.
SQLly: checked, not a problem we have. The reporter's query runs as written. Nothing is substituted or asked for unless you declare it.
Splitting and side effects
SQLite query fails on valid single-quoted string values containing escaped apostrophes and later semicolon HeidiSQL #2469
Age: opened 5 months, 3 weeks ago (April 28, 2026). Confirmed the same day; last vendor reply that day too.
Reactions / comments: 0 / 5.
The vibe: a model bug report. The maintainer boiled it down to SELECT 'abc'';def' in about half an hour and said "Another bug in the SQL parser", which has the sound of someone who has said it before. There was a short detour where GitHub turned & into & and made the bug seem to vanish.
Credit: @zainphp reported it and spotted the HTML-entity mix-up. @ansgarbecker confirmed it with the one-liner. @jonathanp12 tested both variants.
SQLly: checked, not a problem we have. The one-liner and both of the reporter's scripts split correctly on every engine SQLly supports. A guard test now pins all three.
Unexpected SQL execution Sequel Ace #2258
Age: opened 1 year, 4 months ago (June 18, 2025). Last vendor reply 16 months ago. Labelled Need More Info and Low priority.
Reactions / comments: 0 / 1.
The vibe: double-click a cell, and select count(1) from atable where aaa='xxxx' quietly runs against production. The only reply, the day after: "I wonder why the count query is happening … Interesting!" It's been interesting for sixteen months.
Credit: @zouxiaozhu reported it. @Jason-Morcos wondered about it.
SQLly: checked, not a problem we have. Double-clicking a cell only opens the value viewer on your machine. The only count SQLly runs for a result is the one you ask for with Calculate total rows.
Autocomplete
Autocompletion: foreign key join condition suggestions disappear after JOIN ... ON when a WHERE/GROUP BY clause follows in the same statement DBeaver #42381
Age: opened 8 days ago (October 12, 2026). No vendor reply yet.
Reactions / comments: 0 / 1.
The vibe: joins are usually written in the middle of a query that already has its WHERE. If the suggestions only work when ON is the last word in the statement, you rarely get them. The reporter left before-and-after screenshots to make the point.
Credit: @BambinoSK reported it with a full schema and the screenshots.
SQLly: checked, not a problem we have. After ON, both joined tables' columns are offered the same way whether or not a WHERE or GROUP BY follows. A guard test now pins that. (SQLly offers the full ON a.id = b.author_id condition one step earlier, as the join itself, so it isn't something you need after ON.)
PostgreSQL semantic analysis loses column resolution when using EXTRACT(... FROM ...) DBeaver #42293
Age: opened 18 days ago (October 2, 2026). No vendor reply yet.
Reactions / comments: 0 / 3.
The vibe: a careful reporter who came back the same day to show the bug is broader than EXTRACT: SUBSTRING … FROM, TRIM … FROM, OVERLAY … FROM and IS DISTINCT FROM all trip it. A FROM inside an expression gets read as the query's FROM clause. Someone else has since traced it to the grammar and offered a fix.
Credit: @leandrocorrea88 reported it and widened it. @Rishavbhattarai diagnosed the grammar gaps.
SQLly: the FROM-inside-an-expression bug isn't one we have, and all five forms are now pinned by a test. But we ran the reporter's own query, and cal. inside its second CTE offered nothing in SQLly either, because SQLly knew CTEs only by name. Fixed: a CTE's alias now offers its columns, from its select list or its (a, b) column list, in the main query and in a later CTE that reads it.
Autocomplete corrupts the query Sequel Ace #2245
Age: opened 1 year, 5 months ago (May 15, 2025). No vendor reply, ever. Labelled PR Welcome.
Reactions / comments: 0 / 0.
The vibe: the issue text itself got mangled by GitHub, so the reporter had to post the query on Pastebin and attach a video. You add staging at the start of a backticked database name, accept a suggestion, and the query comes out broken. The only response in seventeen months has been a label inviting someone else to fix it.
Credit: @MikeRich88 reported it with a video.
SQLly: we had it too, and it's fixed. Accepting staging_netru_database with the caret inside `netru_database` left `staging_netru_database`netru_database` behind. Now the whole quoted name is replaced, through its closing backtick. A quote you are still typing never swallows text up to some later quote.
Auto Completion Error DbGate #1223
Age: opened 1 year ago (October 17, 2025). No vendor reply, ever.
Reactions / comments: 0 / 0.
The vibe: two complaints in one short report. A DECLAREd @user_name isn't suggested a few lines later, and typing begin picks a stored procedure instead of the keyword. It turned one year old on Saturday, with no reply.
Credit: @KHALED-MSOUTI reported it.
SQLly: half guilty, now fixed. SQLly never swapped begin for a procedure, but it offered nothing for beg at all. And the declared variable was there, just ranked below the half-typed @us itself. Now BEGIN, DECLARE, WITH, MERGE, ALTER, DROP, TRUNCATE TABLE, COMMIT, ROLLBACK, IF and WHILE are offered where a statement starts (including on a new line after a T-SQL statement with no semicolon). @us completes straight to @user_name.
Column names in completion proposal without the need for a table alias HeidiSQL #2439
Age: opened 7 months ago (March 23, 2026). Last vendor reply about 7 months ago. Labelled confirmed and feature.
Reactions / comments: 0 / 8.
The vibe: "Like Navicat" is the whole feature description. The maintainer pointed out it already works if you select the table in the tree first, and later asked for fewer bare @-mentions. The thread is mostly an exercise in patience on both sides.
Credit: @ge00111 asked for it with a screenshot. @ansgarbecker explained the tree-selection route.
SQLly: already have. In a single-table query, SQLly offers the columns by bare name from the FROM clause, whether the caret is before it or after it. No alias needed, and no clicking in the tree. A guard test now pins it.