Press "Enter" to skip to content

Category: T-SQL Tuesday

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.

Leave a Comment

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.

Leave a Comment

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.

Leave a Comment

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.

Leave a Comment

T-SQL Tuesday 194 Round-Up

Published 2026-01-28 by Kevin Feasel

Louis Davidson has made a big mistake:

As I sit here, preparing to write my roundup post, I have not read anyone else’s post yet. I thought it would be good to introduce the idea first, recap to the other posts, then mine. I won’t share any detail of the mistake I shared, but I do want to mention something I included in my post. Types of mistakes. Mistakes of choice, and mistakes of accidents.

Read on for a nice round-up of a popular topic.

Leave a Comment

Lessons Learned from a Trigger

Published 2026-01-21 by Kevin Feasel

Pat Wright tells a story:

I haven’t participated in a #TSQL Tuesday in quite some time.  I saw this topic and said, “That’s perfect!”  I love talking about Failure and mistakes!  I have a whole presentation about it, and I’m hoping to make a series of blog posts about it very soon.   

You do not learn from success in life; you learn from failure.  I hope you are making lots of mistakes so that you can learn! 

Read on for a story from Pat around creating a trigger and not realizing the consequences. This is why we don’t let just anybody have mogwais triggers.

Comments closed

Optimized Locking and Change Event Streaming in SQL Server 2025

Published 2025-11-12 by Kevin Feasel

Deb Melkin is looking forward to a pair of features:

When I look at this release, I feel like I’ve been more tuned into what’s coming out than any other. I’m still not sure how that happened. But I think overall it’s a good thing because there really is a lot being packed into this release. If you’re just trying to figure out now, you’re already behind.

There are really 2 features that I’m really excited about:

Read on to learn more about both of them.

Comments closed

Changes to Backups in SQL Server 2025

Published 2025-11-12 by Kevin Feasel

Steve Jones notes one interesting change to backups in SQL Server 2025:

I’ve been a DBA (or Ops manager) for quite a bit of my career, and one of the things I’ve thought was top priority was backups. I always want to be sure I have a recovery strategy, because if I don’t, nothing matters. Things go wrong and systems fail and I need to protect systems.

Security is a close second, but backups really matter.

Something else backup-related that Steve doesn’t mention is the new form of backup compression using ZSTD. Initial testing of this has been fairly positive and I think it’s worth trying it out as well.

Comments closed

SQL Server Standard Developer Edition

Published 2025-11-12 by Kevin Feasel

Chad Callihan is excited about a limitation:

I had written most of this blog post before seeing this month’s T-SQL Tuesday invite. I decided to hold off a few days to post because, while it’s no secret, I think it’s worth pointing out to those that may not know: before you spend time testing SQL Server 2025, make sure you consider what version of Developer Edition to use.

You may read that and ask, “What do you mean? Isn’t there only one Developer Edition?” That used to be the case, but not anymore.

Read on to see why this is important for a large number of companies.

Comments closed