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.
In the context of cloud databases, a serverless database is one that automatically manages all server resources for you, including scaling up and down based on actual usage, even scaling to zero when not in use. Unlike traditional databases where you provision specific server capacity upfront, serverless databases dynamically allocate resources as needed and charge you only for what you actually consume.
The term “serverless” doesn’t mean there are no servers involved. Servers still exist, but you don’t have to think about them. The cloud provider handles all capacity planning, scaling, and infrastructure management automatically in the background.
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.
A composite constraint is a database constraint that applies to two or more columns together, rather than to a single column on its own.
The most common usage is on primary keys, but composite constraints also show up as unique constraints, foreign keys, and check constraints spanning multiple columns.
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.
JSON_CONTAINS() is a new function introduced in SQL Server 2025 that lets you check whether a value exists at a specific path in a JSON document. It returns an integer. This is 1 if the value is found, 0 if not, and NULL if any argument is null or the path doesn’t exist. That makes it a natural fit for WHERE clauses when you’re filtering rows based on JSON content.
It’s currently in preview (although this will almost certainly change soon) and only available from SQL Server 2025.