SQL Server 2025 ships with a handful of genuinely useful additions, and JSON_OBJECTAGG() is one of the better ones. It lets you aggregate rows into a single JSON object (with key-value pairs pulled directly from your data) without any string hacking or FOR JSON PATH gymnastics.
Here’s what it does, how it works, and when you might actually use it.
If you’re getting SQL Server error 13680 that reads something like “Column ‘details’ on table ‘table_name’ is not of JSON data type, which is required to create a JSON index on it.” it looks like you’re trying to create a JSON index on a non-JSON column. You can only create JSON indexes on columns defined with the JSON type.
To fix this issue, be sure that the column is of JSON type before running CREATE JSON INDEX on it.
In SQL Server, Query Store configuration settings can be adjusted after it’s been enabled to better suit your database’s workload and performance requirements. You might need to increase storage limits, change capture modes, or adjust data retention policies as your needs evolve.
If you’re getting SQL Server error 13681 that states “A JSON index already exists on column…” , it’s probably because you’re trying to create a JSON index on a column that already has one. In SQL Server, each JSON column can have no more than one JSON index.
The solution here is to simply stop trying to create a second JSON index. Another option would be to drop the existing one and create the new one.
If you’re trying to set the ONLINE option when creating a JSON index in SQL Server, but you’re seeing “Invalid usage of the option ONLINE in the CREATE JSON INDEX statement“, don’t worry – it might not be an error on your part.
It probably depends on things like, are you trying to set ONLINE = ON or ONLINE = OFF? And are you trying to do it around the time I write this article, or sometime in the future?
Let’s take a quick look at what could be happening when you try to use this option.
If you’re getting error Msg 5133 and error Msg 3156 in SQL Server, it would seem that you’re trying to restore a database to a different location, but you’re not specifying the different location. This can happen when you restore a database to a different environment that uses a file paths. A common cause of this error is when restoring a backup from a Windows environment to a Linux or Mac environment.
Fortunately, the fix is easy. All you need to do is map the logical file names to paths that actually exist in the new environment.
SQL Server’s window functions allow you to perform calculations across sets of rows that are related to the current row, without collapsing those rows into a single result like traditional GROUP BY aggregates would. When combined with the DATEDIFF() function, they provide a great way to analyze temporal patterns in your data.
Window functions can be especially useful when you need to perform multiple different calculations across the same dataset. Instead of writing separate subqueries or self-joins for each calculation, you can combine multiple window expressions in a single query. This approach is cleaner, more maintainable, and often more performant than traditional alternatives.
SQL Server has a feature called Query Store that maintains a history of all execution plans generated for each query over time. Unlike examining the current plan in cache with SHOWPLAN or execution plan tools, Query Store lets you see every plan the optimizer has chosen historically, allowing you to compare performance across plan changes and investigate regressions.
The following examples assume that Query Store is enabled on your database.
If you’ve spent any time working with SQL Server, you’ve almost certainly run into the “Violation of UNIQUE KEY constraint” error.
It’s one of those errors that can show up in a few different ways depending on how your data flows into the database. Sometimes it’s a data quality issue. Sometimes it’s a race condition. Sometimes it’s just a gap in the logic that nobody caught until production. Whatever the cause, there are quite a few different ways to handle it. Some reactively, some proactively. This article walks through the main ones.
If you’re getting SQL Server error 13683 stating “Invalid JSON paths in JSON index“, it sounds like you could be specifying overlapping paths in your JSON index definition.
A JSON index cannot contain overlapping paths.
To fix this, remove the overlap from the specified paths that make up the index definition.