I’m starting a webinar series about SQL Server indexing with the fine folks of MSSQLTips.com. Each “episode” will be about 30 minutes long and will feature a certain topic of indexes in SQL Server (or related database engines). The target audience are people new to SQL Server or new to the concepts of indexing. So don’t expect technical deep dives like Brent Ozar or Hugo Kornelis, but a beginner-friendly introduction to the various concepts

The first webinar is about clustered indexes and is hosted Wednesday the 25th of March 2026 and you can register for free.

Quite a long title for a short blog post
While deploying a DACPAC (from a SQL Server Data Tools Database Project) through Azure Devops, I got the following error message:

The user attempting to perform this operation does not have permission as it is currently logged in as a member of an Azure Active Directory (AAD) group but does not have an associated database user account. A user account is necessary when creating an object to assign ownership of that object. To resolve this error, either create an Azure AD user from external provider, or alter the AAD group to assign the DEFAULT_SCHEMA as dbo, then rerun the statement.

Guess the SQL Server team didn’t get the memo that Azure AD has been renamed to Entra ID. Anyway, the Azure Devops pipeline uses a service connection defined in Devops, and in that service connection a user-defined managed identity is configured that has contributor access on the resource group that contains the Azure SQL DB. Furthermore, that managed identity is an actual user in the database, so the error message is completely misleading. The error was thrown when the following SQL script was executed:

CREATE SCHEMA myschema AUTHORIZATION dbo;

Turns out, the managed identity didn’t have the CREATE SCHEMA permissions, and it’s not part of the dbo role, so the CREATE SCHEMA script fails with the error above. I created the necessary schemas with a more privileged user and then the deployment pipeline ran without issues.

You can find all the session materials for the presentation “Indexing for Dummies” that was presented at the dataMinds Connect 2025 conference at GitHub.

The slidedeck and the SQL scripts for the session Indexing for Dummies can be found on Github.

I’m giving two online sessions soon on virtual events that are free to attend. The first one is at Retro Data (20th of September), a new virtual conference focusing on established technology, instead of preview features. My session Building the €100 data warehouse with the Azure Data Platform at 10AM UTC+2.

The other session is a brand new one – Indexing for Dummies – and it will be given at the Cloud Data Driven user group (organizers of the Future Data Driven Summit) at the 25th of September (6PM UTC+2). The very same session will also be given at dataMinds Connect btw, if you prefer in-person conferences.

Both events are free to attend, both you need to register through Meetup.

I wanted to try out the new JSON index which is for the moment only available in the SQL Server 2025 preview version. I know, it’s not even available in Azure SQL DB. Cloud not first? What?

I already had a virtual machine in Azure, running SQL Server 2025 CTP 2.0 (which uses a pre-made image). I explain how to set that one up in the article Install SQL Server 2025 Demo Environment in Azure. But I wanted to use the latest preview, which is Release Candidate 0 at the time of writing. Unfortunately, there’s no image available (yet?), so I had to do it the old-school way: installing SQL Server manually.

I created a VM in Azure in pretty much the same way as in the article, except I didn’t pick an image with SQL Server pre-installed, but one with only a Windows operating system.

Once the VM was provisioned, I logged in using remote desktop, enabled Internet and downloaded the RC0 installation media (for which you need to fill in a form to get it). I started the SQL Server installer and launched SQL Server setup:

Most of the setup wizard is “next-next-finish”, so I’ll highlight the important parts. First, you need to pick a SQL Server edition.

New in SQL Server 2025 is that there’s a Standard Developer edition, meaning a Developer edition that only has the features of Standard. I want all the features, so I choose Enterprise Developer.

After accepting the license terms, checking for updates and installation rules, and finally ignoring Azure extension, we get to the feature selection page:

Pretty wild that it fits in one single screenshot. They really removed a lot of features which are now separate downloads (or just gone, like Data Quality Services). For contrast, check out this screenshot from SQL Server 2012:

I only need the database engine and I’m installing it as the default instance, so I skip straight through the instance configuration, where I check the box:

For the server configuration, I picked mixed mode because SQL authentication is a tad easier to use when logging in remotely (use a strong password for the sa account!) and it’s just a test environment. Add your user as an admin.

After that, hit next till SQL Server 2025 is installed (which should just take a couple of minutes).

Inside remote desktop, I can now log into my SQL Server 2025 instance using windows authentication. I also want to log into the database with SSMS from my own machine. I disabled the Windows Firewall (I know, not exactly best practice) and I added port 1433 to the VM firewall:

I also enabled the TCP/IP protocol in the SQL Server Configuration Manager:

After all that, you should be able to connect to the database instance from your local machine:

Don’t forget to prefix the public IP address of your Azure VM with tcp: to make sure the correct protocol is used.

I’m presenting a free webinar at MSSQLTips.com at Thursday, July 10, 2025 at 6PM UTC (8PM CET or 2PM EDT). The abstract:

When you watch some conference sessions, or read some blog posts, it always seems like everyone is drowning in petabytes of (streaming) data. They’re proclaiming you need the fastest, best, most scalable, distributed shared-nothing (or everything?) multi-parallel system that can also get coffee.
But guess what?

• Not every company has to deal with a scale that businesses like Google, Amazon, or Tiktok have to deal with.
• Not every company needs streaming data with Kafka, Spark Streaming or Event Hubs.
• Not every company has complex unstructured data that you need to deal with in a data lake with tools like Databricks.

Some companies have just a couple of gigabytes of data (or even less). Maybe a terabyte if we’re pushing it. They don’t need fancy streaming real-time dashboards, they just want to analyze their financial and sales data. It’s ok if it just runs once a day. Their source systems are regular databases, maybe some Excel files and a SharePoint list. In this session, you’re going to learn how you can build a data analytics platform in Azure that is dirt cheap.
We’re going to cover the following technologies and patterns:

• Cheap ingestion with Azure Data Factory using a metadata-driven framework, in combination with Azure Logic Apps and Azure Functions
• A data warehouse implementation in Azure SQL Database. We’ll cover design best practices and scaling options.
• A Power BI model for presenting the data to the end users

In each section, we’ll look at how costs can be contained. After all, we want a data warehouse which doesn’t cost more than $150 per month!
Note: it’s assumed you have basic knowledge of Azure Data Factory, databases and SQL.

As you might learn from the abstract, the session is aimed at people working with “small data”. Just a couple of gigabytes, biggest table is below 100 million rows. But you would be surprised how many companies actually fall into this category
You can register here. I hope to see you there!

The slides and scripts for my session “Tackling the Gaps & Islands Problem with T-SQL Window Functions” at dataMinds Connect 2024 can be downloaded from GitHub. If you want to run the sample scripts, some of them require an installation of the AdventureWorks DW sample database.

At the 12th of May 2023, a new edition of New Stars of Data takes place. If you’re not familiar with the concept, it’s a free virtual event focusing on the Microsoft Data Platform, organized by the fine folks of DataGrillen. The twist is that only new speakers are allowed; people who have never spoken at an event, or conference. Each new speaker gets a mentor assigned, and this year I had the absolute pleasure of mentoring new speaker Peter Kruis.

Peter has a “back to the core of T-SQL” session. He explains common pitfalls and how you can avoid them. I’ve seen his session a couple of times now, and I can recommend it to anyone who is either new to writing SQL in SQL Server (or any related product such as Azure SQL DB) or has a couple of years experience. His abstract:

Who are you?

You are a SQL developer, but when you handover your code to your senior, you sometimes might hear: “Don’t do this anymore, it’s a bad practice!”. If you want to learn more about those bad practices which I see are being used a lot, this session is for you!

How is this session going to help you?!

In this session you will learn about some of those “code smells”. I will show you an example of the bad practice, explain why it should be avoided and give a possible solution for them. We are going to talk about: Functions in the WHERE clause, Implicit casting, SELECT * and some others. This knowledge will help you make your queries run faster, need less resources and therefore will make your DBA and users happy.

There are also many other great sessions to watch, so be sure to check out the schedule!

Disclaimer: The publisher – Packt – sent me a free copy of the book for the intended purpose of a review. At the time of writing, the book is yet to be released (the date is set at the 22nd of March 2023).

The book SQL Query Design Patterns and Best Practices: A practical guide to writing readable and maintainable SQL queries using its design patterns (that just rolls of the tongue, doesn’t it) is about a topic that’s quite dear to me: writing decent SQL. I’m not saying anything about performance, but I’m rather talking about “well-written” SQL; scripts that are written in such a way they are easy to understand by other people.

There are a whole bunch of authors for this book – six to be exact and they all seem to work for the same company – but fortunately the quality of the book doesn’t suffer from this large fellowship. Some books have so many different authors, it’s hard to find consistency (in writing and style) between the various chapters, but in this book I hardly noticed any difference between the chapters. So a job well done in that regard by the authors and their editors. Most of the authors seem to be working in the field of data analytics and business intelligence (so the same background as myself), which is really interesting as this book is written from a different viewpoint that most other SQL books. It’s not about hardcore performance tuning, indexing or writing very complex SQL stuff, but rather about how to write a query that satisfies the requirements of the business users.

The book itself consists of 13 chapters but most of them are quite short; the total length is about 270 pages, but pages with actual content are about 240. Which I guess is my main criticism: the book often doesn’t provide enough depth. The problem is that if the book would’ve provide more detail, it probably would’ve been over a 1,000 pages since many important topics are tackled.

The first part of the book – Refining Your Queries to Get the Results You Need – consists of 4 chapters who talk about how to write a SELECT statement, how to use a WHERE clause, how to aggregate data, how to format data and how to use certain functions like CASE, COALESCE and ISNULL. This part is really aimed at beginners; people who are just starting to write SQL. If you’re a more seasoned SQL developer, you can most likely skip those chapters.

The second part gets more interesting and talks about common table expressions, window functions, (UN)PIVOT and how security can influence the results of your query. For a book with “best practices” in the title, I was a bit ticked off that none of the SQL statements ends with the semicolon, but they do start each CTE with a semicolon. I know, this is one of those religious wars in SQL, like tabs vs spaces (and don’t get me started on aliases), but it’s called a statement terminator for a reason. The chapter on window functions was nice, albeit short, but it has some great examples. Like most topics in this book, each chapter can easily be a book on its own (like Itzik did with window functions). The security chapter was a bit weird in my opinion. It talks about how row-level-security can be the reason why you don’t get some data returned when you run your query, but it doesn’t really explain what RLS is and how it is set up.

Part 3 has only two chapters: one about execution plans and one about indexing. As with the rest of the book, they merely touch upon those topics. It would’ve been nice if more references for further learning was included (aside from the official Microsoft documentation).

The final part was the most interesting to me (as I was already familiar with all other topics). It talks about how to handle JSON data in SQL Server, the OPENROWSET function (for example to read Parquet data in Azure Synapse Serverless SQL Pools) and Jypiter notebooks in Azure Data Studio. I actually learned some stuff from those chapters.

Conclusion

The book starts with content for beginners, and gradually becomes “more complex” as it goes on, but there’s no real expert content in there. I would recommend this book to everyone starting out with SQL. I believe a book like this could have been beneficial to me at the start of my career