Press "Enter" to skip to content

Category: T-SQL Tuesday

Metadata-Driven Frameworks for Change Detection in Microsoft Fabric

Published 2026-05-14 by Kevin Feasel

Kevin Chant builds a table:

I had various options for this months contribution due to my experience with various change detection solutions. Including Azure Synapse Link for SQL Server 2022. Which I covered in previous posts. Including one that covered some excessive file tests for Azure Synapse Link for SQL Server 2022.

In the end I decided to cover developing metadata-driven frameworks for Microsoft Fabric. Due to the fact that it is such a hot topic for multiple reasons. One of which is the growing availability of open-source, metadata-driven frameworks for Microsoft Fabric.

Read on for three such frameworks and some advice on how to use them.

Leave a Comment

Tracking Data Changes

Published 2026-05-14 by Kevin Feasel

Louis Davidson shows a technique:

A few months ago, I wrote a post about comparing sets of data in SQL, This focussed on a type of challenge that is often a one off challenge. The techniques lists (along with a tool like Redgate’s SQL Data Compare aren’t the point of this post, but they are related because when you do change detection from a source, it is super important to check your results occasionally. Having a copy of the complete source to compare to your destination (even if it is just checksums of the data,) is important.

The techniques that Meagan is asking about this month are more ETL related, where you check a stream of data and sync them as changes are made. Typically, you don’t want to compare all the rows in a set, but just the ones that have changed. At some frequency, give me the changes to one set of data and keep it up to date with another.

I’m still partial to using HASHBYTES() on the fields I care about because I don’t trust modified dates unless I know the only way to access that table is via stored procedure, and all of the stored procedures handle updating the modified date correctly.

For row comparisons, I’d also look at EXCEPT for overall row comparison. You do need to do it in both directions, so the pattern is more like A EXCEPT B UNION ALL B EXCEPT A but it works great and natively handles any NULLs along the way.

Leave a Comment

Tracking Record Changes in SQL

Published 2026-05-13 by Kevin Feasel

Andy Brownsword builds a hash key:

The issue: there was no indicator of which records had been modified and as a result the process took way too long, and downstream reporting wasn’t available on time.

After reviewing and stepping through the process it became clear that the vast majority of data didn’t change. This was a daily process handling 12 months of data, yet over 99% had no changes at all. However the process ingested the whole dataset (~250m records) and processed it in SQL.

Click through for an architectural-level discussion. In practice, HASHBYTES() works really well, especially when you use CONCAT() or CONCAT_WS() to put together the columns you care about

Leave a Comment

T-SQL Tuesday 197 Round-Up

Published 2026-04-20 by Kevin Feasel

Steve Hughes learns something new:

Thanks to everyone who joined the blog party this month. I noticed three themes in the responses. Every response had one or more of these themes woven into their response.

  1. I learned something.
  2. I discovered ways to improve my presentations.
  3. I get more value in the hallway conversations.

Click through for this month’s participants and what they’ve learned.

Comments closed

Presenting for Impact

Published 2026-04-14 by Kevin Feasel

Rob Farley tells a story:

I like this topic from the legendary Steve Hughes. It’s been a long time since I’ve seen him, but he was always a thoroughly good guy. We both spoke at conferences back in the heyday of the SQL community, and although his journey has been tougher than most in recent years, he is still impacting the world in amazing ways.

Steve is hosting this month’s T-SQL Tuesday, and asks about what we’ve learned from conference sessions, things which impacted us and how we work. It’s an interesting topic for two reasons – firstly, I enjoy giving conference presentations, and secondly, they’re really not my preferred way of learning.

Rob goes on to talk about conference sessions that caught his interest. One book that helped me considerably in my ability to present is Peter Cohan’s Great Demo! This is, admittedly, for sales presentations rather than technical presentations. However, I think it’s pretty straightforward to map most of the concepts to technical demos, and the advice in the book is great for getting your point across early and letting people make sure they are in the right room at the right time straight from the get-go.

Comments closed

T-SQL Tuesday 195 Round-Up

Published 2026-02-16 by Kevin Feasel

Pat Wright summarizes this month’s T-SQL Tuesday:

What a great collection of stories all about aging!  I really appreciated everyone take time to reply to the question.  

I’m going to do this a little differently for my summary. I will list the blogs below and provide key summary points for each.  I also created a video summary. I intend to do more of this in the future. 

Click through for the two options.

Comments closed

A Story of Code that Aged Well

Published 2026-02-12 by Kevin Feasel

Hugo Kornelis wrote some code:

The application had clearly been developed by someone who knew just one tool: SQL Server. So he made the database do all kinds of things that really should have been in the application layer. Call external APIs to monitor the primary process of the company. Send fully formatted emails with invoice information. Send formatted HTML and interpret the callback response as a picked menu item. Yes, all that was handled in SQL Server, the frontend app did nothing more than sending query results to the web server and sending HTTP replies back to the database as a parameter into a stored procedure that handled everything.

Read on to see what Hugo was able to do in a one-year timeframe and what it was like coming back to that same code years later.

Comments closed

Coding against the Happy Path

Published 2026-02-11 by Kevin Feasel

Andy Brownsword thinks about successful code:

A common time to revisit old code is when something breaks. I was contemplating Pat’s question this week when a field length change had caused a truncation issue in an old SSIS data flow. Some code doesn’t age badly because it’s wrong, but because it didn’t expect to fail.

It’s all too easy to write a piece of code which ‘does the thing’, run a few variant tests, and send it on its way. But will it stand the test of time? That’s where my good and bad code diverge, and I usually revisit the code and find the old milk.

Admittedly, I’m not as good at this as I should be either. It can be a challenge to think through the possible issues that could arise and develop code to mitigate or eliminate those issues. But as Andy points out, it can be critical to success.

Comments closed

Preventing Legacy Code

Published 2026-02-11 by Kevin Feasel

Deborah Melkin shares some tips on preventing code from becoming “legacy code”:

This is an interesting question. In some ways, it’s hard to say how my code has aged. no one is yelling at me that my code is breaking production, so that’s a good sign. I have definitely talked about times where I wish I could go back and do something differently because it would have been a little bit smarter to do. I’m no longer at some of those companies and one of them doesn’t even exist in that incarnation anymore so I have no clue how that code is being used or if it even got fully implemented. I’ve done a lot of reviews of other people’s code and the most problematic legacy code was the code that would have been problematic at the time it was written but was good enough to get by.

Read on for a couple of broad tips that can help keep your code from becoming “legacy code” in the pejorative sense of the term.

Comments closed

Being a Steward of Code

Published 2026-02-11 by Kevin Feasel

Louis Davidson shares a perspective:

So not only do I know how some of my code has aged, I am constantly reminded of it. I think of it in different ways:

  • How well the code was written in the first place
  • If it is still in use
  • If it can be/has been modified by someone else (or even you)

Some of this can be a challenge given external constraints, like needing to get it in production now-now-now! But I do like the way Louis thinks about the problem.

Comments closed