You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks a lot for the beta launch of the MSSQL Server Plugin for Tabularis.
I am a daily MS SQL Server user from an analyst and DWH requirement engineering perspective. That means I am a heavy "reader," but I don't write structures or manage the server.
The MS SQL dialect-specific TOP() instead of LIMIT is currently not correctly implemented:
When I use right-click → generate SQL → SELECT [Fields]
(I use the German language version, so the naming might not be exact),
I get a query using LIMIT.
Furthermore, when I edit it or write a query myself with TOP, it still does not work and returns the following issue: Error: SQL Server error 102: Incorrect syntax near '100'. [syntax error; severity 15; state 1; line 11]; SQL Server error 102: Incorrect syntax near 'OFFSET'. [syntax error; severity 15; state 1; line 11]; SQL Server error 153: Invalid usage of the option NEXT in the FETCH statement. [statement failure; severity 15; state 2; line 11]
Happy to use the plugin more intensively and provide more feedback, once the issue is resolved.
Thanks for the report and for offering to provide more feedback!
After checking the code, this appears to involve two separate issues:
Tabularis generates LIMIT 100 regardless of the SQL dialect in “Generate SQL → SELECT fields.” For SQL Server, it should generate SELECT TOP (100) ….
The plugin adds OFFSET … FETCH pagination even when the query already uses TOP. SQL Server does not allow these together in the same query scope, which explains why manually switching to TOP still fails.
My proposed fix is to make SQL generation dialect-aware in Tabularis, and have the plugin leave queries with an explicit outer TOP or OFFSET/FETCH unchanged. Regular SELECT queries would retain automatic pagination.
What do you think of this approach? Would you be interested in collaborating on a PR for either part? No pressure at all—testing the fix against your everyday queries would also be very helpful!
Thanks again for the detailed report! Both parts of this issue are now fixed and merged:
Generate SQL → SELECT fields generates SQL Server SELECT TOP (100) instead of LIMIT 100, with schema-qualified and bracket-escaped identifiers.
The plugin preserves explicit outer TOP and OFFSET/FETCH clauses instead of adding conflicting pagination. Ordinary SELECT queries still use automatic pagination.
The complete fix requires both:
Tabularis nightly 0.25.1-6 (download), or the next stable release. The stable release is currently planned for later today, subject to the release checks.
We verified the changes with 29 live SQL Server integration tests, including generated SELECT execution with host pagination enabled, explicit row limits, identifier escaping, and guarded UPDATE/DELETE previews. The host and plugin CI checks are also passing.
Please choose nightly 0.25.1-6 or newer: the macOS 0.25.1-5 bundles had an unrelated runtime-version packaging bug, fixed in TabularisDB/tabularis#835. We verified that the actual signed ARM64 0.25.1-6 app reports the correct runtime version, loads plugin beta.3, and executes a TOP (3) query correctly even with a requested page limit of 2.
The nightly is now fully published for Windows, macOS (ARM64 and Intel), and Linux x64, with updater entries verified for all four targets. Plugin beta.3 is published for all five supported plugin platforms.
Please update both the app and the plugin, then try your usual queries again. We would really appreciate your feedback from everyday SQL Server/DWH use!
Activity
debba commentedon Sep 21, 2026
Thanks for the report and for offering to provide more feedback!
After checking the code, this appears to involve two separate issues:
LIMIT 100regardless of the SQL dialect in “Generate SQL → SELECT fields.” For SQL Server, it should generateSELECT TOP (100) ….OFFSET … FETCHpagination even when the query already usesTOP. SQL Server does not allow these together in the same query scope, which explains why manually switching toTOPstill fails.My proposed fix is to make SQL generation dialect-aware in Tabularis, and have the plugin leave queries with an explicit outer
TOPorOFFSET/FETCHunchanged. Regular SELECT queries would retain automatic pagination.What do you think of this approach? Would you be interested in collaborating on a PR for either part? No pressure at all—testing the fix against your everyday queries would also be very helpful!
debba commentedon Sep 29, 2026
Thanks again for the detailed report! Both parts of this issue are now fixed and merged:
SELECT TOP (100)instead ofLIMIT 100, with schema-qualified and bracket-escaped identifiers.TOPandOFFSET/FETCHclauses instead of adding conflicting pagination. Ordinary SELECT queries still use automatic pagination.The complete fix requires both:
0.25.1-6(download), or the next stable release. The stable release is currently planned for later today, subject to the release checks.1.0.0-beta.3(download).Plugin fixes: #30 and #31. Matching host change: TabularisDB/tabularis#818.
We verified the changes with 29 live SQL Server integration tests, including generated SELECT execution with host pagination enabled, explicit row limits, identifier escaping, and guarded UPDATE/DELETE previews. The host and plugin CI checks are also passing.
Please choose nightly
0.25.1-6or newer: the macOS0.25.1-5bundles had an unrelated runtime-version packaging bug, fixed in TabularisDB/tabularis#835. We verified that the actual signed ARM640.25.1-6app reports the correct runtime version, loads plugin beta.3, and executes aTOP (3)query correctly even with a requested page limit of 2.The nightly is now fully published for Windows, macOS (ARM64 and Intel), and Linux x64, with updater entries verified for all four targets. Plugin beta.3 is published for all five supported plugin platforms.
Please update both the app and the plugin, then try your usual queries again. We would really appreciate your feedback from everyday SQL Server/DWH use!