fix(sql-editor): correct T-SQL/Azure SQL result paging

[cursor]

Bug and impact

Result paging for Azure SQL and many SQL Server SELECTs was broken:

1. Azure SQL fell through to the MySQL/Postgres LIMIT … OFFSET … wrap, which is invalid T-SQL. Page 0 fell back to an unwrapped query; Next fail-closed with Paging failed.
2. SQL Server / Azure SQL queries with a top-level ORDER BY were nested as SELECT * FROM (… ORDER BY …) …, which SQL Server rejects in a derived table. Same fallback / broken Next path. Queries without ORDER BY used ORDER BY (SELECT NULL), so pages could skip or duplicate rows.

Root cause

wrapSqlForPage only treated sqlserver/mssql as T-SQL (missing azuresql) and always wrapped into a derived table with a dummy outer order, instead of appending OFFSET/FETCH when the statement already had a top-level ORDER BY.

Fix

• Treat azuresql as T-SQL (OFFSET … FETCH NEXT …).
• When a top-level ORDER BY is present, append OFFSET/FETCH to the original SQL so sort order is preserved and the statement is legal.
• Otherwise keep the derived-table + ORDER BY (SELECT NULL) wrap.

Validation

• Unit tests for Azure SQL wrap, ORDER BY append, and top-level ORDER BY detection.
• npx vitest run apps/web/src/backend/api/sql-page-wrap.test.ts apps/web/src/backend/api/sql-execute.test.ts — 21 passed.

  

---

Note

Medium Risk
Changes generated SQL for live database paging in the SQL editor; mis-detection of ORDER BY could still produce wrong pages, but scope is limited and well-tested.

Overview
Fixes broken Next paging and invalid SQL for Azure SQL and SQL Server in the SQL editor by correcting how wrapSqlForPage builds paged queries.

Azure SQL is now treated like other T-SQL dialects (OFFSET … ROWS FETCH NEXT …) instead of falling through to Postgres-style LIMIT/OFFSET, which Azure rejects.

For T-SQL, when the user query already has a top-level ORDER BY, paging appends OFFSET/FETCH to the original statement instead of wrapping it in SELECT * FROM (… ORDER BY …), which SQL Server disallows and which also preserved sort order incorrectly when only a dummy outer ORDER BY (SELECT NULL) was used.

A new hasTopLevelOrderBy lexer-style helper ignores ORDER BY inside subqueries, strings, comments, and bracketed identifiers so the append-vs-wrap decision stays safe. Queries without top-level ORDER BY still use the derived-table + dummy order wrap. Unit tests cover Azure SQL, ORDER BY append paths, and detection edge cases.

^{Reviewed by Cursor Bugbot for commit 91a654c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_c115f57e-7b47-403b-9667-da960078651f)