If you’re getting an error that reads “JSON aggregates do not support order-by within group when specified with grouping sets, cubes and rollups. Try your query without order-by within group.” it looks like you’re trying to use the ORDER BY clause inside a JSON aggregate function when using GROUPING SETS, CUBE, or ROLLUP.
To fix this error you’ll need to remove ORDER BY from the aggregate function when using those clauses.
If you’re getting SQL Server error 8110 that reads “Cannot add multiple PRIMARY KEY constraints to table…” it’s because you’re trying to add more than one primary key to a table. In SQL Server, a table cannot contain more than one primary key.
It’s quite possible you were trying to create a composite primary key, and so you might need to fix your syntax. If that’s the case, read on.
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.
Before SQL Server 2025, indexing JSON data meant creating a computed column to extract the value you cared about, then indexing that column. It works, and it’s still a solid approach, but it requires you to know upfront which paths you’ll query, maintain separate columns for each one, and keep those columns in sync with any schema changes. SQL Server 2025 introduces JSON indexes as a native alternative. It’s a single index structure that covers the JSON column directly, without the computed column overhead.
JSON indexes are currently in preview and only available in SQL Server 2025 on-premises. They aren’t available yet on Azure SQL Database, Managed Instance, or Fabric. That said, things could be different by the time you read this article.
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.