SQLlyCompetitor watch: does the grid tell the truth?
12 open results-grid bugs from DBeaver, DataGrip, Beekeeper, DbGate, HeidiSQL, Sequel Ace and Azure Data Studio, checked against SQLly. Two were ours.
A results grid has one job: show you what is in the database, then let you copy, export and edit exactly that. So I read twelve open issues from seven other SQL clients where the grid quietly disagreed with the data, and checked every one against SQLly.
SQLly had two of them. Both are fixed in SQLly 1.9.0. The other ten I checked and SQLly does not have, and one of them talked me into a small new feature.
This is the first of a running series. Every day 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: a clear repro, often a diagnosis. They deserve the credit, so every one is named and linked below. Ages are as of October 19, 2026. "Vendor" means someone the tracker marks as a member, collaborator or staff.
The twelve issues
Decimal values exported to JSON don't match values shown in result grid Azure Data Studio #26344
Age: opened 1 year, 3 months ago (June 27, 2025); last vendor reply 1 year ago. Reactions / comments: 0 / 2
Export SELECT 5656.555 to JSON and you get a different number back. A Microsoft engineer couldn't reproduce it, and the reporter came back the next day with the cause (the Windows regional format, Spanish-Colombia in their case) and a workaround. The thread has been quiet ever since: a bug report that arrived with its own diagnosis, now waiting a full year.
Credit: @hanercamilo reported it and found the locale trigger; @kburtram (Microsoft) tried to reproduce it.
SQLly: checked, not a problem SQLly has. Exports write decimals digit for digit and never consult the system locale.
When filtering Exports don't respect filter Azure Data Studio #26194
Age: opened 1 year, 8 months ago (February 11, 2025); no vendor reply, ever. Reactions / comments: 0 / 0
Filter the grid, select all, export to Excel, and you get the right number of rows, just not the right rows. It's a sneaky kind of wrong, because the count looks fine. Twenty months, no reply.
Credit: @hfoxwell reported it.
SQLly: checked, not a problem SQLly has. Export and copy use the filtered, sorted rows on screen, and a filter that hides every row exports nothing, not everything.
Editing decimal number with German locale causes the decimal seperator is removed Azure Data Studio #26222
Age: opened 1 year, 7 months ago (March 7, 2025); no vendor reply, ever. Reactions / comments: 0 / 0
Change 2.3 to 2.5, save, and the database now holds 25.0: a factor of ten from one keystroke. This one has been waiting long enough to see two Oktoberfests.
Credit: @BegoRubarth reported it.
SQLly: checked, not a problem SQLly has. Edited numbers are read the same way on every locale and decimals go to the server exactly as typed. A new test now pins that down.
"Copy to Clipboard" only copies the last column when there are duplicate column names Beekeeper Studio #4818
Age: opened 20 days ago (September 29, 2026); labelled bug and accepted, no comments yet. Reactions / comments: 0 / 0
SELECT 1 num, 2 num, 3 num, copy it, and two of the three columns vanish. A short, clean repro, accepted quickly by the maintainers.
Credit: @whiteandgold reported it.
SQLly: SQLly had a cousin of this one, honestly. TSV, CSV and Markdown copies were fine, but JSON wrote {"num":1,"num":2,"num":3}, which every JSON reader collapses to the last value. Fixed in 1.9.0: repeated names become num, num_2, num_3, the same as the SQL and Excel exports. Thanks for the nudge, Beekeeper.
IN statement pasted from 'Copy for IN statement' are in a misunterpreted format Beekeeper Studio #4779
Age: opened 27 days ago (September 22, 2026); the vendor replied within minutes. Reactions / comments: 0 / 3
Copy a column "for IN", paste it into the table's IN filter, and the first value silently drops out, the worst kind of wrong because nothing errors. To their credit, the Beekeeper team agreed on the fix the same day and a community member diagnosed the exact cause and offered to take it on. It has been fully explained for weeks; it's waiting on someone to land it.
Credit: @ygu reported it; @not-night-but proposed stripping the parentheses; @rathboma agreed the filter should accept that format; @cipherprofessor traced the root cause and offered a fix.
SQLly: I checked and SQLly had the same gap in a different shape: its "Copy for IN" writes a whole predicate ([Id] IN (1, 2, 3)), and pasting that into the grid's IN filter would have kept the ( on the first value. Fixed in 1.9.0: the IN box now unwraps pasted lists, reads quoted SQL text properly, and filters on every value.
Different NULL types Beekeeper Studio #4732
Age: opened 1 month, 12 days ago (September 7, 2026); last vendor reply 1 month ago. Reactions / comments: 0 / 3
A JSON null and a SQL NULL look identical in the grid, though IS NULL treats them differently. The maintainer asked for a screenshot and the reporter couldn't share one, so it's stuck at "please send a picture".
Credit: @lorypelli reported it and added the MySQL version; @rathboma asked for a screenshot.
SQLly: checked, not a problem SQLly has. A JSON null shows as the text null; only a real SQL NULL gets the NULL marker, and a new test keeps it that way.
Result grid cells alternate between NULL and actual values while scrolling DBeaver #42319
Age: opened 13 days ago (October 6, 2026); last vendor reply 4 days ago, labelled wait for response. Reactions / comments: 0 / 2
Scroll through already-fetched Trino and Iceberg rows and values flicker to NULL and back, the kind of bug that makes you distrust everything else on screen. The ball is with the reporter, who has been asked for a video.
Credit: @surmikk reported it; @davestokes thanked them; @ShadelessFox (DBeaver) asked for footage.
SQLly: checked, not a problem SQLly has. Rows still loading draw as blank space, never as NULL, and values already fetched don't change while you scroll.
Data grid never renders the final rows of a result set DbGate #1501
Age: opened 3 months, 14 days ago (July 5, 2026); last vendor reply 3 months, 9 days ago. Reactions / comments: 0 / 4
The footer says 249 rows, and the grid shows 245 no matter how far you scroll. The maintainer couldn't reproduce it and asked for the data; the reporter went well beyond the call and offered a live database to test against, then politely asked in September whether anyone had looked. Still no answer. The last four rows are out there somewhere.
Credit: @risehkdev reported it, compared it against pgAdmin and followed up; @Stelinkaa (DbGate) tried to reproduce it.
SQLly: checked, not a problem SQLly has. The row count and the scrollable range come from the same number, and a finished result is always readable through its last row.
Table duplicates some rows and omits others DbGate #1537
Age: opened 2 months, 6 days ago (August 13, 2026); no vendor reply, ever. Reactions / comments: 0 / 1
Page size 50, filter, sort, and some rows show up twice while others go missing. The total stays correct, so you'd never notice without hunting for duplicates. The reporter came back with a public, step-by-step reproduction; it has sat since.
Credit: @ezwelty reported it and posted a public reproduction.
SQLly: checked, not a problem SQLly has. SQLly doesn't page table data with OFFSET; sorting and filtering run over the whole result, so a row can't land on two pages.
Pressing Down on last row of a non-editable query result triggers "Grid editing error" HeidiSQL #2596
Age: opened 1 month, 10 days ago (September 9, 2026); no vendor reply yet, labelled bug. Reactions / comments: 0 / 0
You're just reading a join result with the arrow keys, you hit the bottom, and a modal accuses you of trying to edit two tables at once. The reporter even pointed at the code in HeidiSQL's source that seems to cause it, which is most of the triage done for free.
Credit: @Friedrich2 reported it.
SQLly: checked, not a problem SQLly has. Arrow keys stop at the last row; navigation never adds a row, editable result or not.
Multi-line changes using "Edit as Table" only update the first row DataGrip DBE-27126
Age: opened 1 month, 4 days ago (September 15, 2026); submitted, triaged and assigned, no comments yet. Reactions / comments: 0 votes / 0
Paste into ten rows of a big CSV, the IDE says ten rows changed, and git says one did. When the UI and the file disagree, the file wins, and you find out at commit time. It's assigned, so it's on someone's list.
Credit: Lejia Chen reported it, with a sample project and a screencast.
SQLly: checked, not a problem SQLly has: each pasted row is its own saved change, and only rows that will be saved get marked. (SQLly doesn't edit CSV files as tables, so that half is moot.) But it made me notice SQLly had no spreadsheet-style fill at all, so 1.9.0 adds it: paste one value or row over a selected range and it fills every selected row, each one a real staged edit you can review before saving.
Data grid scrolls horizontally on cell inline update Sequel Ace #2652
Age: opened 1 month, 8 days ago (September 11, 2026); no vendor reply yet. Reactions / comments: 0 / 0
Edit a cell in a wide table, press an arrow key, and the whole grid lurches sideways until your column is pinned to the right edge. Small, but it happens on every edit, and it adds up.
Credit: @klimenttoshkov reported it.
SQLly: checked, not a problem SQLly has. The grid scrolls only when the selected cell is out of view, and then only by the minimum.
What's next
Tomorrow is another batch. If you reported one of these, thank you: a clear repro is a gift to every tool that reads it, not just the one you filed it against. The fixes and the new fill-down are in SQLly 1.9.0, and every issue checked is listed there too.