T-SQL Tuesday #191: Invitation–Your Favorite String Parsing

It’s that time of the month, and I’m late. My apologies. I had a mix-up with a host and was on vacation all last week, so no invite.

I’m extending T-SQL Tuesday #191 a week to have people write on Oct 21, 2025. My apologies. The invite is below, something that’s been on my mind with all the AI work I’ve been doing, but I thought I’d ask about something more SQL related.

I’m looking for hosts for 2026. Blogging is a great way to grow your brand and help you impress potential future employers.

Your Favorite String Parsing Routines

One of the things that I’ve had to do a log in my career is parse strings in different ways. It seems our customers constantly find new ways to stick data into a string that we would prefer to have normalized in some way for searching, indexing, etc.

As a few examples, we might get someone who creates a PO that looks like 20260720321433, where there’s a year/month to start and then a number. We might need to parse either the number or the date from the field to determine when or which count of a PO someone has made. Other examples might be someone putting “Sam Jones” in the last name (surname) column because there isn’t a middle name space. We might need to get just the last name out of the field.

This year (2025) I’ve been using AI often to try and get data from various structures, often PDFs or more complex formats, but I have managed to ask AI to change a bunch of data in a field across different rows rather than try and work out some RegEx search and replace. That got me thinking.

What are your favorite string parsing routines that have helped you handle complex situations? That’s your invite for Oct 2025. Write on a way that you’ve handled parsing (and maybe replacing values) in complex strings.

I see questions on things all the time at SQL Server Central. A few examples:

  • [Doe, Jane E] [Doe Smith, Jane E] (get the without middle/initials/etc)
  • [Hello5-E-100] (get the final number)
  • 192.168.1.100 – parse IPv4 (or v6) addresses
  • Parse XML for a value
  • Parse JSON for a value
  • [8/9/08 – out for upgrade; 8/16/08 returned to inventory. 8/31/2008 – deployed to field] – parse out all the dates

Write on Oct 21, 2025, a week late, and post a comment on this post linking back to your entry. I’ll compile everything next week for the roundup. The rules:

  • Publish the post before 2025-10-21 11:59:59
  • Include the logo above
  • Link the logo to this invite
  • Make a comment on this post (or trackback/linkback)
Posted in Blog | Tagged , , | 8 Comments

Republish: Start Fixing Your DB with Better Code

Still in Italy, so while I’m sipping wine, you can Start Fixing Your Database with Better Code.

I realized I never put this on the blog, so here it is:

Start Fixing Your DB with Better Code

I ran across an interesting article from Gitlab. They host git repositories for companies that develop software, and of course, part of their hosting is tracked in a database. They use PostgreSQL for their data, and were not happy with the performance of their database backing the system. Up front they admit part of the issue is their own coding, which is likely the problem in so many software projects.

Gitlab accepted this, and certainly many database developers or consultants will let management know that the problem causing poor performance is often poorly written code. Jeff Moden constantly explains in his articles how better code can dramatically reduce the load on your SQL Server, yet fixing code is often the one thing few organizations want to focus on. It’s easier to buy more hardware, which often just hides the problem for am all-too-short period of time. Or just complain and try to write new features that take the place of old ones.

I’m sure many of you have heard your parents or teachers tell you it takes about as long to do something right as wrong, so do it right the first time. Often taking a shortcut doesn’t really save time. I’m not sure that’s true with development. Often it’s quicker to do it wrong because doing it right takes a little more planning, and perhaps some testing, likely a bit more time to carefully construct code, and certainly more time to learn how to write code better. That last item is the issue, as so many of us learn to write code poorly, without examples that give us good habits from the start.

The best developers have spent lots of time writing code poorly and learning how to improve their work. They know the tips and tricks in their language(s) of choice. That might be better SQL to create efficient queries, better C# to avoid constantly hitting the database, or something else. However, as most of us learn to write code, we don’t learn the best way. We learn the ways that are easiest to teach a user concepts, most of which don’t scale well.

If you’ve made the investment to learn about writing better code, then it doesn’t take any longer to write good code from the start. If you’ve made the investment, and if you practice what you’ve learned. Jeff has lots of great articles on writing better code, as do many of our other authors. Take a few minutes today and learn to build better SQL code. Your database (and users) will thank you.

Steve Jones

Posted in Editorial | Tagged | Comments Off on Republish: Start Fixing Your DB with Better Code

Republish: Getting Fired

I haven’t been fired as a DBA, but I was asked to resign. It was a tough day, though a big relief as my boss was a ****head.

I’m traveling around Italy with my wife, so you get to re-read Getting Fired.

Posted in Editorial | Tagged | 2 Comments

A Short Break

It’s holiday week for me. I was in the Netherlands last week for Pass on Tour and the Redgate Summit. My wife joined me and we are taking a break this week, wandering around Northern Italy.

See you next week. Hopefully refreshed and recharged.

Posted in Blog | Tagged | Comments Off on A Short Break