Press "Enter" to skip to content

Curated SQL Posts

Major Security Update for SQL Server

Published 2026-03-12 by Kevin Feasel

Rebecca Lewis digs into an important patch:

Yesterday was Patch Tuesday, and this month we’ve got a good one. CVE-2026-21262 was already publicly disclosed before Microsoft shipped the fix – and it lets an authenticated SQL Server user escalate straight to sysadmin. SQL Server 2016 through 2025, Windows and Linux. No physical access required. No user interaction required. Just a valid login and a network path to your instance. Go patch!

If you’re a SQL Server DBA or consultant and you’re reading this before patching, stop reading and go patch.

Read on for more information about the vulnerability and how to make sure you’re on the latest CU or GDR for SQL Server.

Also, the fact that there are fixes going back to 2016 doesn’t mean that 2014 and earlier are fine. It just means that Microsoft is serious about not patching versions 10+ years out of date.

Leave a Comment

LOB Logical Reads and Columnstore Indexes

Published 2026-03-11 by Kevin Feasel

Brent Ozar notices a difference:

Forever now, FOREVER, it’s been a standard thing where I can say, “When you’re measuring storage performance during index and query tuning, you should always use logical reads, not physical reads, because logical reads are repeatable, and physical reads aren’t. Physical reads can change based on what’s in cache, what other queries are running at the time, your SQL Server edition, and whether you’re getting read-ahead reads. Logical reads just reflect exactly the number of pages read, no matter where the data came from (storage or cache), so as long as that number goes down, you’re doing a good job.”

But this is not always the case, as Brent demonstrates.

Leave a Comment

Dynamic Data Masking Isn’t Security

Published 2026-03-11 by Kevin Feasel

John Sterrett provides a reminder:

SQL Server Dynamic Data Masking (DDM) is one of those SQL Server features that is commonly misused as a primary security feature used in production. Since it landed in SQL Server 2016, I’ve seen teams throw it at compliance requirements and call it a day, only to find out later that their “masked” data was completely readable by anyone willing to spend 20 minutes in SSMS.

Let me show you some data masking limitations in SQL Server when used for security, and what you should be doing instead (or alongside it) if you’re serious about Zero Trust data security.

I think John is a bit kinder to the value of Dynamic Data Masking than I am. Even so, this article shows several major problems it brings to the fore.

Leave a Comment

Eventstream Not Sending Data to KQL Database after Resuming Fabric Capacity

Published 2026-03-11 by Kevin Feasel

Olivier Van Steenlandt troubleshoots an issue:

To continue the development of my mobile app, whose core ability is to scan barcodes of consumable articles and send them over for analytics, I’m resuming my capacity, starting to scan barcodes again, sending them to my Eventstream, and finally saving them in my KQL database.

After a couple of minutes, I wanted to validate all the scanned results in my KQL database and navigate to my scanned_barcode table.

Read on to see how Olivier diagnosed and corrected the problem.

Leave a Comment

Data Extraction from Unstructured Data with Fabric AI Functions

Published 2026-03-11 by Kevin Feasel

Sandeep Pawar demonstrates functionality:

Most enterprise data lives in free text – tickets, contracts, feedback, clinical notes, and more. It holds critical information but doesn’t fit into the structured tables that pipelines expect. Traditionally, extracting structure meant rule-based parsers that break with every format to change, or custom NLP models that take weeks to build. LLMs opened new possibilities, but on their own they bring inconsistent outputs, no type of enforcement, and results that vary between runs. What production workflows need is LLM intelligence with structured-output guarantees, delivered inside the data platform teams already use.

Microsoft Fabric AI Functions deliver exactly that. Functions like ai.summarize, ai.classify, ai.translate, and ai.extract let you transform and enrich unstructured data at scale with a single line of code – no model deployment or ML infrastructure needed. For the full list, see Transform and enrich data with AI functions.

Click through for an example. The tricky part of this is, because answers won’t be deterministic, you have to do a lot of testing and verification to ensure things are working reasonably well.

Leave a Comment

NTILE and Uneven Row Distribution

Published 2026-03-11 by Kevin Feasel

Jared Westover clarifies:

One of the simplest yet least-popular ranking functions in T-SQL is NTILE. It’s useful for dividing data into buckets or tiles. However, when your data isn’t evenly distributed across buckets, the results are confusing. Also, NTILE sometimes returns rows in a seemingly random order. What’s happening here?

There’s absolutely a pattern to how NTILE() works, as Jared describes.

Leave a Comment

UDFs to Support the Like-for-Like Pattern in DAX

Published 2026-03-11 by Kevin Feasel

Marco Russo and Alberto Ferrari support a pattern:

DAX user-defined functions (UDFs) are a powerful tool for improving the quality of your semantic models. DAX authors with an IT background are accustomed to creating generic code using functions. However, many DAX creators came from different backgrounds of expertise, such as statistics, business, and marketing. They may not recognize the immense power that functions have brought to the Power BI community.

In this article, we want to practically show, through an example, how to wisely use functions to improve the generalization of code and to reduce the complexity of your semantic models, with the goal of raising curiosity towards user-defined functions and – in general – the world of code development.

Read on for an example, as well as a link to the like-for-like pattern and what it means.

Leave a Comment

Logging and Error Handling with MicrosoftFabricMgmt

Published 2026-03-10 by Kevin Feasel

Rob Sewell continues a series on the MicrosoftFabricMgmt Powershell module. First up is structured logging:

If you have ever come back to a script the next morning and thought “what on earth happened last night?”, you understand why logging matters. Write-Host and Write-Verbose are fine for interactive use, but in automation — scheduled tasks, CI/CD pipelines, long-running jobs — you need something more structured. Something you can query, filter, and persist across sessions, something that you can provide to your team or support or auditors.

MicrosoftFabricMgmt uses PSFramework for all its internal logging, and that capability is available directly to you.

Then comes retry logic and dealing with long-running operations:

REST APIs fail. Networks are unreliable. Cloud services have rate limits. If your automation script does not account for this, it will eventually break at the worst possible moment. This is not pessimism — it is production experience.

MicrosoftFabricMgmt has a lot of error handling built in, so you do not have to write it all yourself. Today I want to show you what the module handles automatically, and how to add your own handling on top for the scenarios you care about.

Leave a Comment

An Introduction to pg_duckpipe

Published 2026-03-10 by Kevin Feasel

Yuwei Xiao needs a way to move data:

When we released pg_ducklake, it brought a columnar lakehouse storage layer to PostgreSQL: DuckDB-powered analytical tables backed by Parquet, with metadata living in PostgreSQL’s own catalog. One question kept coming up: how do I keep these analytical tables in sync with my transactional tables automatically?

This is a real problem. If you manage DuckLake tables by hand, running periodic ETL jobs or batch inserts, you end up with stale data, extra scripts to maintain, and an operational surface area that grows with every table. For teams that want fresh analytical views of their OLTP data, this quickly becomes painful.

pg_duckpipe addresses this. It is a PostgreSQL extension (and optionally a standalone daemon) that streams changes from regular heap tables into DuckLake columnar tables in real time. No Kafka, no Debezium, no external orchestrator. Just PostgreSQL.

Click through to learn more about how it works.

Leave a Comment

The Transaction Log as a Circle

Published 2026-03-10 by Kevin Feasel

Paul Randal explains to the officer that the transaction log is a flat circle:

In the second part of this series, I described the structural hierarchy of the transaction log. As this post is chiefly concerned with the Virtual Log Files (VLFs) I described, I recommend you read the second part before continuing.

When all is well, the transaction log will endlessly loop, reusing the existing VLFs. This behavior is what I call the circular nature of the log. Sometimes, however, something will happen to prevent this, and the transaction log grows and grows, adding more and more VLFs. In this post, I’ll explain how all this works, or sometimes doesn’t.

Read on for a depiction of the transaction log and what can cause it to foul up.

Leave a Comment