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.
If you’ve spent any time around data teams or analytics tools, you’ve probably heard the term ETL thrown around. It sounds technical, but the concept is actually pretty straightforward. This article looks at what the term actually means, how it works, and why it matters.
A time series database (TSDB) is a database built specifically to store and query data that’s tied to timestamps. This could include things like sensor readings, stock prices, server metrics, or IoT data. Basically anything where the when is just as important as the what.
Standard relational databases can technically store this kind of data, but they weren’t designed for it. Time series databases are optimized from the ground up for time-ordered data, which means they’re faster, more efficient, and more practical for time-heavy workloads.
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.
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.