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.

I have a session called “Conquering the Monster Proc: How to Combat Legacy Code.” It’s about strategies for tackling that stored procedure in the database that does way too much, is central to the application, has been around forever, and is starting to fall over spectacularly in prod so you finally have to do something about it. I remember debuting this session at PASS Data Community Summit. At the Q&A section at the end, I got this question:

How do you prevent your code from becoming legacy?

I love this question. If I remember correctly, my answer was that unfortunately, you can’t. Databases change – in size, in schemas, usage, etc. Database versions change – SQL Server 2022 was just released when I gave that session and fast forward to now SQL 2025 went GA a few months ago. If you wrote your code for SQL Server 2016 or 2017 and are starting your upgrades now to get ahead of the end of life, there may be a lot of new functionality and updates that will change how the optimizer works, whether you know it or not. Where you host your database may change – server or data center upgrades, new hardware options, virtual machines, migrations from on-prem to cloud, etc. Your code may have been just what you needed for the time you wrote it but all of these things that are now out of your control have just changed on you. That alone made your code legacy.

But there are things you can do to help make it easier to manage when it becomes time for you to deal with those issues:

• Document your code. What are you really trying to accomplish? What does this section of code do? You may not be around but it would definitely be helpful for the next person. It may even help you if it’s been awhile since you’ve look at the code. A week can feel like an eternity sometimes. And when possible, don’t just say “Bob told me to make this change”; I may not know Bob or Bob is no longer around to ask so add a little bit of their reasoning to those comments. Add comments not just to the proc code directly but to source control as you check things in. I like comments in code so I can tell if the right version has been released. I like comments in source control check-ins so everyone can easily see what change was made when and by whom.
• Follow best practices. I’ve seen some code over the years. As I said earlier, the legacy code that I find is the most problematic and hasn’t aged well was code that never was best practice to begin with. In some cases, it may have solved one issue but underlying set up may have changed so either that issue is occurring again and no one knows it or it never really worked the way it was thought to. In some cases, someone didn’t know what the best practices were and didn’t follow them. I remember the senior developer who told me they thought that all SELECT statements should either be read uncommitted or snapshot isolation. All I could do is tell them that not only these two were not interchangeable and did not work the way they thought they did but the real issue is that the table was missing an index. There’s a lot of educating we have to do so it’s making sure we do the best we can to make sure that the code is following as much of best practices as possible.
• Accept that your code will never be perfect. It’s really hard to do but it’s about picking our battles. As I said before, we don’t know what changes are coming around the bend but if we do what we can now, maybe it won’t be so painful later.

As we move through our career, I think we find that there is always code we want to revisit and improve because of what we know now. We’re not always going to get that chance and sometimes, it’s not creating a problem so it’s OK as it. Hopefully if we do our job right, no one will notice if our code doesn’t age well.

I’m looking forward to hear your stories. In the meanwhile, I’m off to write some future legacy code. Thanks again to Pat for hosting this month!

Let’s be honest – there are just too many mistakes to talk about it, which is why I chose the quote from the rock band Queen as my post’s title. Those of us who are speakers and bloggers probably already have at least one session and/or blog post about what they’ve learned from a past mistake, usually multiples of each.

The one that falls in that category for me is a technically minor mistake that didn’t appear in testing but did when rolled out to production for our internal system. I missed a simple concatenation between fields so I wasn’t passing the correct server name used by a dynamic SQL statement. We didn’t have a lot of logging as part of this process at that point; there was some updates to a control table but it was really on a very high level. After we stopped the job initially and rolled out the fix, I noticed something that originally took 6 minutes to complete suddenly hadn’t finished after 20+ minutes when we ran it again. We didn’t have enough insights to figure out what happened at the time. The short version of the story is that we figured out that because we were using OPENROWSET, the stored procedure must not have gotten the message that we stopped the SQL Agent job and continued to run and hold locks, blocking the newer version of the proc. We didn’t have the information to prove this other than retrying the whole process the next day and having it work as expected.

Most of the lessons I learned can be found in my blog posts, Dynamic SQL: Sessions and Execution and OPENROWSET, Dynamic SQL & Error Handling, and inspired my session Mastering Dynamic SQL. I learned something the hard way so hopefully you can benefit from those lessons.

The other major lesson I learned: I will always create log tables for any process that has multiple steps run repeatedly for different systems, especially if it requires dynamic SQL. I applied this lesson learned with a different project and the amount of information we gained – including performance baselines, auditing for external verification, and visibility as the process ran – was invaluable to the success of that project on multiple levels.

I’m still amazed how one small minor mistake like a typo can lead to a massive number of major lessons learned.

But not all mistakes that we learn from are done in production. A lot are made as we’re on our way there. I’m currently working on a new session that I’m presenting at SQLCON 2026 about CDC and Change Event Streaming. I just learned a few days ago that there is a difference in the way that you set up change event streaming in the database for the AMQP Protocol vs the Kafka protocol. Most of the setup is the same, but there are two key values for parameters that make the difference. It ended up being a simple mistake on my part where I didn’t read the documentation properly so I used the wrong value wrong for one of those params. But I did have to step away from the computer and come back to it the next day to figure that out. And now I have a lesson from my mistake to share with my audience: “I messed this up so you don’t have to.”

This is why development and other test environments are so important. We need a place to make the big and small mistakes so we can learn our lessons before they’re deployed to prod. Lower environments are interesting because they’re development, QA, UAT, and production environments for engineers all at the same time. We need these instances to be all the things so that by the time everything is deployed or set up in production, the mistakes, fixes, and lessons we’ve learned are eliminated and the known issues that can easily be fixed. More importantly, if we treat the lower environments like production, we can be more confident of how to quickly handle those issues in the moment. Then we’ll just be left with the unknown and unexpected issues to fix, but hopefully we can keep those down to a minimum or be better equipped to handle them quickly because of the other lessons we’ve learned along the way.

Thanks again to Louis for hosting this month! Here’s to a new year of us making lots of mistakes to learn from and hoping that they’re not in production!

It’s hard to believe but 2025 is out the door. It’s only fair that I take a moment on reflect on the year before looking forward to 2026. Because it has been a year….

A quick recap of 2025:

It was definitely a hard year personally. We said good-bye to my mom at the end of March. It feels like I dropped off the planet for a bit around that time, which was necessary. But it also felt like it took a while before I could really bounce back to doing things.

But there were some good things that happened. I was able to speak at a couple of big conferences like SQL Bits, PASS Summit on Tour, Redgate Summit and PASS Data Community Summit, along with Data Ceili, SQL Saturdays NYC and Boston. I also got a chance to speak at some user groups as well. I did some more videos for my YouTube channel. I was able to contribute to the T-SQL Tuesday posts, as well as host one.

Other things that I’ve been doing this past year – I’m still one of the co-chairs for the Data Platform WIT UG with Tracy Boggiano and Kristy Mishra. We’ve been talking about how we can continue to expand our support for our community, so expect to see more from us down the road. I’m also still running WITspiration with Tracy, which is a data platform WIT focused mentoring group. I feel like I haven’t given this group as much attention as I have wanted to give it, so my goal is to give it more attention over the next year. By the way, we are accepting new members to WITspiration, so if you’re a women in tech in the data platform space who wants to mentorship, we’d love to have you! You can find the sign-up form here.

So what do I have coming up in 2026:

• I’m excited to be picked to speak at SQLCON in Atlanta in March. I’m both excited and nervous for this as I’ll be delving in to a new topic for me; it will be a challenge but I’m looking forward to sharing with all of you who will be there. I’m also going to be leading the WIT Panel at Data Saturday Chicago. I know there are a couple of other speaking opportunities that will pop up as dates and conferences get announced. (And if you’re looking for speakers, feel free to reach out!)

• I’m still a part of the Data Platform WIT UG and WITspiration so you’ll definitely see me talking more about supporting women in tech along with mentoring over the next year.

• I still plan on blogging. I am hoping to do more of the cross-bloggging\vlogging, where the video on YouTube will be shared here with text. I have a bunch of ideas that I want to talk about, but as always, it’s finding the time to put together the topics.

• There’s always going to be something new around the corner. I’m horrible at predicting what those are, but I’m looking forward to seeing what opportunities present themselves and being open to them.

• Self-care is important so I’m also going to work on making sure I don’t overdo things and that I can organize myself in a way where I can get to the things I want to do without guilt if I can’t get to the nice-to-do items on my list.

One final thought as I look over the past year – it feels like there’s a lot of change going on in our larger data platform community. This change is on many fronts – new conferences, changes to conference structures, names of conferences, changes in organizers, changes in people’s level of involvement, etc. Change is always hard but I think the key is making sure we’re adapting with it and making sure we’re listening to the community as to what it wants and needs. I love being involved with this community so I’m going to continue to find ways to be involved in whatever way I can and encourage others to do the same.

Here’s looking forward to what 2026 brings and looking forward to seeing what we all accomplish in this new year!

(This month’s T-SQL Tuesday is hosted by Mike Walsh (blog). He’s asked us to get reflective and introspective and write notes to ourselves. The first is to ourselves 10 years ago and the other is to our current selves from 10 years in the future, or 2035.)

Hey there, 2015 Deborah:

It’s me, or rather, you in the year 2025! Just wanted to let you know that this idea you’ve been tossing around – starting a blog – is going to be one of the best things you do for yourself. You’ve been thinking about getting more involved in the professional SQL Server community by doing things like going to the user group meetings more regularly and even trying to attend those SQL Saturdays that have been popping up in Boston and the rest of country\world. The inspiration you’re getting from them will pay off. I know you’re going to overthink it (and unfortunately you’re never going to stop that part) but your blogging is going to be a great entry way into the community. You’re going to get involved in this community that inspired you. You’re going to find a way to give back through blogging and mentoring and even becoming co-leader of the Data Platform Women in Tech User Group! Not only is it going to give you opportunities to grow professionally, but you’re going to meet so many wonderful people, make some amazing friends along the way, and help others start on the same journey as you. Take advantage of the opportunities in front of you and trust that you know what you’re doing.

Hey there, 2025 Deborah:

It’s me, or rather, you in the year 2035. I know that 2025 was quite a year for us in many ways. And you already have a lot that you want to do for 2026 and are already stressing about how to get those done. I’m here to tell you that you’re going to do just fine. Remember that you don’t have to do all the big things but you will still make huge impacts with the little things. But you’re also going to make sure you prioritize yourself as well. You have a lot of friends and resources available to help you and together, good things are coming down the road. The next 10 years are going to be quite the journey but you’re already prepared for it. Now enjoy it!

Happy T-SQL Tuesday! It feels like it’s been a while since I was able to put one of these posts together. So thank you to Steve Jones for this month’s topic, which makes it really easy to write a post and join the party. Steve asked to talk about what we’re excited about with SQL Server 2025.

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:

The first is optimized locking, which is what my session at PASS Data Community Summit is about, coincidentally. This feels like the first major change to the locking mechanism of SQL Server in a very long time. I used to say that locking and isolation levels is usually about reading the data or writes not blocking reads. The shift here is that optimized locking is about writes not blocking writes as well. Let that sink in for a moment.

Optimized locking makes heavy use of Accelerated Database Recovery (ADR) and its introduction of the persistent version store. Instead of locking and holding the key of records being updated during transactions, optimized locking will lock and hold the transaction id, a 14 byte identifier added to every record, for the length of the transaction. This means that the lock used to update the row itself can be released quickly, reducing the need for lock escalation.

When you turn on Read Committed Snapshot Isolation as well, optimized lock can determine if a row that is already part of another transaction would be affected by your change and if so, it will wait for the row to be available so you can make your update based on those new changes. Accelerated Database Recovery was introduced in SQL 2019 but it doesn’t seem to get as much attention as it should. Optimized locking has been available in Azure SQL DB since 2023 so it’s nice to see it being made available on-prem. If you haven’t fully convinced your developers to stop using NOLOCK everywhere, this should be the functionality to do it.

The second is feature that I’ve been really trying hard to find time to investigate a lot more: Change Event Streaming. It’s an alternative to Change Data Capture (CDC). CDC has two default SQL Agent jobs. The first looks at the transaction logs for specified tables and writes the before and after changes to system tables. The second manages the retention period, where it deletes records older than the specified duration. The purpose of CDC is to be able to share the individual changes with additional process or even data pipelines. This means having to have different connections come to the database to select the changes needed. This means there’s a bit of overhead that you have to account for. Change Event Streaming (CES) is a new feature that looks for those transactions and sends them to Azure Events Hub to be consumed by various connectors. No more extra writes to your database. And if your CDC previously was being picked up by a pipeline and passed off to a connector, this may help you consolidate a few steps along the way. I know it’s not going to be the solution for every case where we need CDC, but I’m really intrigued by CES’s potential. I definitely want to see more.

As I said earlier, there are a lot of things being introduced in SQL Server 2025. There are more of these types of big changes as well as lot of small ones that I think will have big impacts. Even being able to test out the release candidates, I find it’s hard to get to everything. But I’m looking forward to putting together something in a couple of years saying, Did you know they released this way back in SQL Server 2025?

Thanks again to Steve for hosting this month (and keeping this blog party going, which I know is NOT an easy task!) Looking forward to seeing what everyone else is looking forward to.

It’s time for another video! This time, join me as I walk through Creating a SQL Server docker container using VS Code. As a bonus, I’ll also show you how to create a PostgreSQL server in a docker container.

Hope you find this helpful and let me know your thoughts!

I do have some links at the end as reference. They are:

• https://learn.microsoft.com/en-us/sql/tools/visual-studio-code-extensions/mssql/mssql-extension-visual-studio-code?view=sql-server-ver17
• https://docs.docker.com/engine/install/
• https://debthedba.wordpress.com/2020/09/04/installing-docker/
• https://debthedba.wordpress.com/2020/09/30/docker-sql-server-and-ports/

As an added bonus, I’m including my transcript below along with tips about where I am in the video. I know some people prefer to read than watch so hopefully a combination of the two will make it easier to see if the video has the info you’re looking for and where to find it. If you find this useful, let me know!

Hi everyone! My name is Deborah Melkin. I’m Deb the DBA. That’s my blog. That’s my YouTube channel, and that’s my GitHub. I’m a Microsoft MVP for the Data Platform. I wanted to take a moment and talk about creating a SQL Server Docker container from VS Code, from Visual Studio Code. I know that’s not a lot of words we usually put together in the Data Platform, but it’s a really useful thing to have. For those of you who don’t know what a container is, it’s essentially a virtualized instance of an application. Or at least that’s how I’d like to think about it. It makes a lot more sense. We know virtual machines, which is essentially a virtualization of an entire server. A container is a smaller portion of that. It’s just the application. It just has what we need to run an instance of SQL Server. So we don’t have to worry about multiple instances of SQL Server on our local machine, for example, or maybe we just need something temporarily. So we can create a Docker container for just that
version and then get rid of it once we don’t need it anymore. It’s a really quick and easy way to spin up a SQL Server so we can do whatever sort of testing we need and then move on.

Now they’ve made some changes in improvements and the Microsoft SQL Server extension as part of VS Code. And this is one of those hidden little things where if you don’t know to look, you may miss it, but it’s really useful. So I thought we take a moment and take a look. Alright, let’s jump over to VS Code.

(video: 00:01:39)
Here we are in VS Code. The first thing I’m going to to do is go to my SQL Server extension. I have it on the sidebar here, SQL Server, clicking that. I don’t have any connections set up, but that’s all right. What we’re going to do is we’re going to create a local SQL container right here. There’s also an icon for this above here. All I do is I click and now we have the welcome page for creating a local SQL Server database container.

Great, we have information here if interested. I’m going to go ahead and choose get started. First thing it does as it goes through the prerequisites. Starting with, do you have Docker installed? If you don’t, all you have to do is click the link. It will take you to the pages so you can then install it. I don’t have it here yet. So let
me go install it and I’ll be right back.

(video: 00:02:29)
All right, I’ve installed Docker. I’m all set up. So now we’re back in VS code starting over. I’m going to create my local SQL container. I’m going to say get started. It goes through the check. Everything is up and running. We’re ready to go next.

(video: 00:02:43)
The first thing we do is select the version of SQL Server we want. We have everything from 2017 to 2025. Notice we’re only being given the latest version. So if you need to do something more specific, let’s say you do need a specific CU install for whatever test you’re doing. This may not be the right one thing to use. We’re talking about getting a quick start for containers. So I’m just going to choose SQL Server 2025
latest. I’m going to create a password and I’m going to save it because when it’s done, it’s going to have that connection saved for me. I’m going to create a profile name, demo test. I’m going to leave the connection group alone for now. Advanced options, I always like specifying a container name.

Port. My default SQL Server port is 1433. For my containers, I like to specify a port. Part of the reason is if I had a local instance installed, my port is 1433. If I were to leave that port here and choose the default 1433, there may be cases where I’m not necessarily connecting to the correct instance. I have a blog post about this that I did several years ago. You’ll find that in the resources. So for now, I’m going to choose 2025. For some reason, I like coordinating the ports with the version of SQL Server I’m using. We’re just going to go with that for now. And I’m going to go ahead and specify a host name. I like keeping those the same. The last thing that I do is I accept my terms and conditions.

And then I’m going to create my container. If you haven’t pulled your SQL Server image, it may take a couple minutes for that you to do that. But now we can see as creating container, it’s now setting everything up.

And just a few moments, we’ll be able to connect to our container. And we’re done. I’m clicking finish. And we can see our connections over here, DemoTest. It’s actually kind of cool if you look. Let’s see if I can zoom in. Oh look, it’s the icon for a Docker container. So we could even see right here that this is a container. And now I can connect. And I can get started with my SQL Server pretty much like any other. And now I’m often running.

(video: 00:05:04)
Now that we have our SQL Server Docker containers up and running, we want to be able to manage to. Now, we can do that through Docker desktop or PowerShell or other tools that are available to us. But we can also do that through VS code through extensions.

I’m going to go through my extensions. And I’m going to look up “Docker”. And I have the extension here. I’m going to go ahead and install this. And we should be able to add at this to our sidebar: “Containers”. And now I can do management of our containers from here. We can see I have the SQL Server 2025 latest.

This is the container we just created. We can see the image that it’s using. If we had a lot more Docker containers set up and more intricate connections, and volumes. And that’s sort of thing. We would be able to see those here. But we just created the very basic Docker container. But we can see that from here. So if we wanted to, we could stop this. We could start it if it was stopped. So we can do some basic container management right from VS code.

(video: 00:06:12)
Now, I don’t know about you. But I find there’s a lot of pressure these days to be multiple database platform. Our data is a multiple different places; everyone’s using different things for it. So we need to be able to go from one to another. And as a SQL server DBA, I don’t know about you, but PostgreSQL is the one that I’m constantly hearing about.

So we’re talking about creating Docker containers for SQL Server, can I do it for Postgres? Well, let’s take a look.

(video: 00:06:44 )
There happens to be an extension of VS code for post-cress from Microsoft. And I’ve already set that up. So let me click here. I don’t have Postgres installed. So now I
need to create a server. And there’s an icon for that. Create a new server.

One of these options isn’t available yet, but I’m really curious about that. Create an Azure database for Postgres. That’s kind of cool. But we’re talking about Docker containers today. So let’s go do that.

Let’s see what happens here. Create my local create local Docker Postgres server. Okay, I’m going to choose get started. First thing it does is make sure that Docker is installed up and running, which it is. Going to hit continue. So let’s create a name: LearnPostgres. And that’s going to be my container name. I’m going to keep the username and use the default. Create a password. Save that so it’ll connect. Choose the default database name and server group. There are some advanced options. But for now, I’m just going to go ahead and take the default. So I’m choosing create.

Just a couple clicks of the button will wait for everything to get set up. And there we are. Here’s my server and my databases are here. So that was pretty quick. I can now be learning Postgres. I’m off and running. Maybe don’t tell my manager how easy that is, huh?

(video: 00:08:15)

There you have it. With a couple clicks of the button, we were able to set up our databases in Docker container. Pretty easy. Now, if we need something a little more complicated, this may not be the best method. But if we need a quick start, this
is a great way to get started.

I’m leaving you with a couple resources that I like doing that in case you have any other question. I’ve included a couple blog posts that I had written a one about installing Docker and the other is about SQL Server port numbers. As I mentioned earlier, you want to be really careful if you have things like named instances or multiple Docker containers running that are all using that default 1433 port. It’s
a little gotcha if you didn’t know you needed to look at for it.

I hope you found this useful. If so, leave a comment, let me know. And with that, have fun and I’ll talk to you next time!

It’s another T-SQL Tuesday! Our host this month is Taiob Ali (b). (Thanks for hosting this month, Taiob!) He’s asked us to talk about how AI is changing our careers.

The pressure is definitely there to use AI every day and embrace it or be gone. When I think about my relationship with AI, I think these vignettes may help explain it better:

My coworker is helping me with a problem. It’s the classic “the script works on their machine but not mine.” They suggested we use the AI tool all the developers are using. I had coincidentally remembered to finally install it that morning in my VS Code; I don’t actually don’t use it that often. My coworker walks me through the prompts and we hit run.

It’s actually kind of cool. In the side window, the tool is telling me its thought process as I see the changes in the output terminal. I left the code compare window up so I can see the changes through the different iterations. A few minutes later, it’s done. The final output script looks pretty good and the initial problem is fixed. Right?

Until the coworker looks at how the tool modified the code. Turns out that we can’t use it because it removed other code that needed to be there and created a new file that won’t work, along with a bunch of other problems.

Alright, back to the drawing board….

Did you see my video on getting started with Vector Searches in SQL Server 2025? I was able to take the code examples that have been shared publicly with us and walked through the steps with my own database and got it to work. I was even able to walk through the documentation to set up Azure AI Foundry to create a model. While it’s an oversimplified explanation of what vectors are and how they work, I’m proud of myself for being able to understand the basics of what things are in a way that hopefully makes sense to others to help them get started as well.

The next question is where do I go from here? I have some ideas of what I want to try next. Hmm… can AI help me find time for that?

The vendor showed us their AI offerings. Afterwards, we’re standing around talking about what we just saw and thinking about how it all works. Someone says something and next thing you know, we’re debating what this particular functionality is, how it works and is it really what we think it is. I’m fairly confident I understood it, but I still had to go home and research one of the pieces…

I think the reason for the debate came down to there’s a lot of nuances and differences between the various types of AI and their use cases. It’s nice when vendors can do the demos, waiving all of the hands to make it look good. But when talking to technical people, we should stop the magic show and lift the table cloth to show what’s going on with the architecture underneath. We need to understand the specifics of the tech we’re working with and the differences between them all. Everything is based off of a “model”, but there are so many different types and we use them all in different ways. It’s easy to be confused.

This is where I feel I should throw in a shout out to Muazma Zahid‘s LinkedIn post series, #LearnWithMZ. I so appreciate when people are evangelists not just for the product and company they work on but the underlying tech behind it.

It’s not just Muazma. Many people are blogging about the different use cases they’re coming up with on how to integrate various types of AI. I’m reading them and am curious to see where these all go. I’m attending various sessions at conferences or online on how people are using AI or just learning the fundamentals. There are so many different areas that AI can be applied – from summarizing documents, to extracting text from unstructured data like images or sound files, to identifying manipulated images which may indicate fraud, to helping write or analyze code, or even to just have better search abilities with data we already have. There’s a sense that we’re all trying to learn at once because it’s early stages of its maturity. In the meanwhile, it’s great to read some of the cool things that are going on, along with the cautionary tales like Replit. We all know where our Responsible AI Guidelines are, right? RIGHT?????

That reminds me – Our office is on a “AI all the things!” kick. We have dedicated resources and slack channels just for talking and sharing all things AI. I need to remember to add some of these blog posts there…

Y’all, I am really tempted. What would it write for me? I’ve been so overcommitted – how am I going to have time to pull together a new post? My poor blog has been neglected! Is this the answer?

But my brain always turns to my friends who are professors and I know they know how to identify work that their students did not do themselves. AI tools are also known to steal copywritten work and other content without permission or accreditation or just make up things that don’t exist. People are submitting what is generated by AI tools without confirming what was generated was right. If you think people don’t know that your output is from AI, you’re wrong; tools exist to identify these things. And it’s not just because there’s an em dash in there somewhere. These tools may not always be right, but do you really want to take a chance?

This doesn’t even begin to cover the deepfake videos that are getting better in terms of quality. It’s quite scary when you realize how much harder it’s becoming to recognize what’s real and fake.

It’s not to say that I haven’t used ChatGPT to help me with a session title or to massage the body of an abstract or to get an idea of how to construct what I want to say. I know people use it to write their self reviews at work or refine their comments to better corporate speak to align with the higher ups. It’s more useful in those situations than I may care to admit.

But when it comes to my blog, the English major in me has too much pride in being able to say that these written words are mine. Every last misused word, awkward phrase, and grammatical mistake. (Apologies to all my English teachers and professors.) Not just that, I want to ensure that what I’m saying is correct and reflects what I want to say. I guess I’m probably going to have a big “trust but verify” – or rather “don’t trust, just verify” – caveat when it comes to AI, especially when it comes to the content I’m creating.

So what’s the TL;DR version of how am I using AI right now and how’s it changing my career? It depends….

Let me know your thoughts!

If you want to get started, here are some references for SQL Server 2025:

• What’s New in SQL Server 2025: https://aka.ms/sqlserver2025docs
• SQL Server Launch Blog: https://aka.ms/sqlserver2025
• Download SQL Server 2025: https://aka.ms/getsqlserver2025

When I first got started as a DBA, I tended to think of SQL Agent jobs as more of an operational tool – you use it to just back up your database, run index maintenance, etc. But I found myself using SQL Agent jobs more and more for various uses: I need to add an index to a large table as part of a deploy but the installer connection string only allows for 30 seconds and it will take significantly longer. So I can have my install script create a job that will run one time during a downtime to add that index. We need to have functionality that sends messages to Service Broker queues that then have to be pulled down and processed as a way to simulate real-time analytical cubes and dimensions: Create SQL Agent jobs as part of the deploy that sets up and runs the process if the system is configured to collect the data. I probably have a bunch of other examples like these. If your application relies on the database processing something and working, using agent jobs is a great option.

How do I manage this all?

I have scripts to create and modify SQL Agent jobs.

And those scripts get checked into source control.

And those scripts get added to the deploy process.

And most importantly, those scripts get tested in all environments from development through production.

Those last 3 points are the most important. When we treat database as code, the jobs are also code and should be treated as such. This means they need to be deployed reliably and repeatably. If there are changes needed to the jobs, I have the scripts make the proper modifications and I test those as well.

I’m pretty “old-school” when it comes to how I do this. I usually script out the jobs from SQL Server Agent using Management Studio and then make the modifications in the SQL scripts from there. Part of the reason I do this is that there are certain parameters that need to be set, especially for the job schedule, that I still find easier to set up from the UI. I usually have the same script create and modify the job so my SQL can get pretty involved – or at least it looks that way. This is where commenting and formatting the scripts makes a difference.

Over the years, there have been a variety of pushback from application developers when it comes to scheduling processes against the database that’s more than just database maintenance. There are all sorts of schedulers and other workflow tools, like Orkes, that can be used for these types of jobs. If you’re in Azure SQL DB, SQL Agent isn’t an option and you may have to rely on Elastic Jobs or some other Azure offering. Even if SQL Agent is an option, I have still seen pushback against it since it’s part of SQL Server and that somehow translates to having business logic in the database, which they don’t want, or they’d rather use these other schedulers for a variety of reasons. In some ways, I don’t care what gets used. I still maintain that whatever you are using to run regular processes against a database, you should find a way to check your code into source control so you can repeatably and reliably test and deploy your jobs.

Let me know what you think about this. Thanks again to Andy for the great topic. As always, I’m looking forward to reading everyone else’s thoughts.

• To find out more about T-SQL Tuesday, check out: https://tsqltuesday.com/
• To find out more about the invitation from Erik (and find more on his blog), check out: https://erikdarling.com/t-sql-tuesday-185-video-star-edition-tsql2sday/
• To find more of Erik’s videos, check out his YouTube channel: https://www.youtube.com/c/ErikDarlingData
• To find out more about my YouTube channel, check out: https://www.youtube.com/@debthedba