- SqlPackage or DacFx Version: Microsoft.Build.Sql 2.2.0 / 2.3.0-preview.2, Microsoft.SqlServer.DacFx 170.5.60-preview
- .NET Framework (Windows-only) or .NET Core: .NET 10.0.302
- Environment (local platform and source/target platforms): Windows 11 → SQL Server 2022 (Sql160)
Steps to Reproduce:
- Create an SDK-style SQL project targeting
Sql160
- Add a stored procedure or view that uses the SQL Server 2022 named
WINDOW clause:
CREATE PROCEDURE [dbo].[ExampleProc] AS
BEGIN
SELECT
ROW_NUMBER() OVER [win] AS [RowNum],
SUM([Amount]) OVER [win] AS [RunningTotal]
FROM [dbo].[Transactions]
WINDOW [win] AS (PARTITION BY [AccountID] ORDER BY [TransactionDate]);
END
- Build the project with
dotnet build
- Build fails with:
Build error SQL46010: Incorrect syntax near 'OVER'.
Expected Behavior:
The project builds successfully. The WINDOW clause is valid, generally available T-SQL syntax that shipped with SQL Server 2022 (compatibility level 160), documented at:
https://learn.microsoft.com/en-us/sql/t-sql/queries/select-window-transact-sql
Actual Behavior:
Build error SQL46010: Incorrect syntax near 'OVER'.
The ScriptDom parser does not recognize the named WINDOW clause syntax and fails to parse the T-SQL.
Versions Tested:
| Component |
Version |
Result |
| Microsoft.Build.Sql |
2.2.0 |
❌ Fails |
| Microsoft.Build.Sql |
2.3.0-preview.2 |
❌ Fails |
| Microsoft.SqlServer.DacFx |
170.5.60-preview |
❌ Fails |
| SQL Server (target) |
2022 (16.x) |
✅ Works |
| Target Platform (DSP) |
Sql160 |
— |
Did this occur in prior versions? If not - which version(s) did it work in?
This has never worked in any version of DacFx or Microsoft.Build.Sql. The named WINDOW clause was introduced in SQL Server 2022 (November 2022) and the ScriptDom parser has not been updated to support it in any release since — including the latest preview (170.5.60-preview, August 2026).
This follows a pattern of SQL Server engine features shipping without corresponding ScriptDom/DacFx parser support, previously seen with IGNORE NULLS (#133) and GENERATE_SERIES (#105). Both were treated as bugs and resolved.
Impact:
Teams using the WINDOW clause for cleaner, DRY window function definitions are forced to rewrite all named window references as inline OVER (PARTITION BY ... ORDER BY ...) definitions. The workaround is functionally identical but more verbose and harder to maintain.
Workaround:
Replace named WINDOW references with inline OVER() definitions:
-- Instead of this (fails to build):
SELECT
ROW_NUMBER() OVER [win] AS [RowNum],
SUM([Amount]) OVER [win] AS [RunningTotal]
FROM [dbo].[Transactions]
WINDOW [win] AS (PARTITION BY [AccountID] ORDER BY [TransactionDate]);
-- Use this (builds successfully):
SELECT
ROW_NUMBER() OVER (PARTITION BY [AccountID] ORDER BY [TransactionDate]) AS [RowNum],
SUM([Amount]) OVER (PARTITION BY [AccountID] ORDER BY [TransactionDate]) AS [RunningTotal]
FROM [dbo].[Transactions];
Steps to Reproduce:
Sql160WINDOWclause:dotnet buildBuild error SQL46010: Incorrect syntax near 'OVER'.Expected Behavior:
The project builds successfully. The
WINDOWclause is valid, generally available T-SQL syntax that shipped with SQL Server 2022 (compatibility level 160), documented at:https://learn.microsoft.com/en-us/sql/t-sql/queries/select-window-transact-sql
Actual Behavior:
The ScriptDom parser does not recognize the named
WINDOWclause syntax and fails to parse the T-SQL.Versions Tested:
Did this occur in prior versions? If not - which version(s) did it work in?
This has never worked in any version of DacFx or Microsoft.Build.Sql. The named
WINDOWclause was introduced in SQL Server 2022 (November 2022) and the ScriptDom parser has not been updated to support it in any release since — including the latest preview (170.5.60-preview, August 2026).This follows a pattern of SQL Server engine features shipping without corresponding ScriptDom/DacFx parser support, previously seen with
IGNORE NULLS(#133) andGENERATE_SERIES(#105). Both were treated as bugs and resolved.Impact:
Teams using the
WINDOWclause for cleaner, DRY window function definitions are forced to rewrite all named window references as inlineOVER (PARTITION BY ... ORDER BY ...)definitions. The workaround is functionally identical but more verbose and harder to maintain.Workaround:
Replace named
WINDOWreferences with inlineOVER()definitions: