A Fine Slice Of SQL Server
Shane Borden lays out an argument:
The short answer is always “maybe”. However, in the following post, I hope to demonstrate what creates a sub-transactions and what happens to the overall transaction id utilization when they are invoked. I will also show how performance is affected when there are lots of connections creating and consuming sub-transactions.
Click through for some testing and results.
Leave a CommentJason Yousef shows off a capability in Pytest:
Pytest is one of those tools that feels obvious after you’ve used it for a bit. Tests are just functions. Assertions read like normal Python. And when you need context—database sessions, config, mock data—you reach for fixtures instead of duct tape.
Read on to see how they work. Admittedly, I don’t think I’ve used fixtures before in Pytest, but now seems like a good time to try it.
Leave a CommentAndy 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 CommentRob Douglas ran out the clock:
My preview trial of 2025 was evaluation version, and if you let that run past 180 days your SQL instance just will not start. I had an old Azure VM that I fired up to grab some code from a SQL Agent job I had been playing with and hit exactly this problem. Here’s the workaround:
Click through for the process. Fortunately, Rob doesn’t stop at how to get the instance up again, but continues into installing a non-evaluation version.
Leave a CommentLouis 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 CommentDeborah 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