A New Word: Foilsick

foilsick – adj. feeling ashamed after revealing a little too much of yourself to someone – allowing them too clear a view of your pettiness, your anger, your cowardice, your childlike vulnerability – wishing you could somewhat take back the moment, bolting the door after a storm had already blown it off its hinges.

What a visual. The door blown off its hinges from a storm, and you desperately trying to set it back into the opening.

Blurting out something in an emotional moment is likely something many people have done. I would guess parents as much as teenagers feel foilsick after an argument or a moment of passion in which they say something they didn’t mean.

In the modern world, we might do that with messages or emails as well. I find myself trying to avoid putting myself into the place where I might feel foilsick and I often take a moment to draft something in Joplin (my notetaking app) before I put it into Slack or email. I can’t accidentally send it and then feel some regret over what I said.

I think the avoidance of ever feeling foilsick often leads many of us to not say something we feel, or admit a challenge, precisely so that we aren’t vulnerable and regret our words. As I grow older, I realize that being vulnerable isn’t going to create a foilsick feeling in many cases. It’s going to bring me closer to someone else, or help them help me.

From the Dictionary of Obscure Sorrows

Posted in Blog | Tagged , | 1 Comment

Reducing Cloud Cost

Cloud costs are high and growing. Some orgs think they’re out of control and are trying to limit spend. Some orgs are looking to leave the cloud. A lot of IT spend over the years has been seen as a cost center, with many executives trying to limit the growth or spend, even while they aim for digital transformations of their businesses. Throughout my career, it’s been interesting seeing the tension of groups trying to take advantage of technology and the finance departments trying to manage costs.

The cloud brings some of the same debates/arguments/concerns to the forefront. Partially because of scale, as we can add cloud resources much quicker than we can with a CapEx purchase. Partially because we’ve also often lost some control over budgeting with the move to OpEx and the subscription paradigm.

However, the bigger problem is that we get a true chargeback for all the resources we use. This is done in a way that exceeds what I used to see with mainframes. In those days each department got a monthly report of their usage, applied against their budget. In the cloud world, finance gets a real bill they have to pay, and the chargeback is not a made-up number for internal use.

How can you reduce the cost in the cloud for your database (or all data) resources? The easy answer to start is to get rid of those resources that aren’t being used. How many databases have been created for dev/test and aren’t actively used? That’s often an easy chore, and one that could be scripted. Though I’d want to include backups of anything I get rid of that might be reused. That might include dev systems rarely used. Keeping a backup that I can use to restore to a new resource later is always a good idea.

In line with this, you might look for underutilized instances, especially for VMs or expensive services like Managed Instances. There can be a cost overhead for these systems, and if every application/department/etc. uses a separate system, there might be cost savings from consolidation. However, don’t just move databases. Ensure you aren’t creating a security risk or overloading the system with moves. That requires some analysis of the current systems and buy-in from those with security concerns.

However, the biggest win in reducing cloud cost is to performance tune your code. This is something many DBAs request on a regular basis, but often there isn’t any push to write better code, or utilize better patterns of querying that might reduce the amount of CPU, memory, and network traffic. Learn how to write better performing queries, limit the data returned (no SELECT *), watching out for datatype conversions, and using other techniques that people write about at SQL Server Central every day. We constantly answer questions and publish articles on better ways to write code, so invest the time to ensure your teams can and do write better code. Make sure you train your staff and they use their training.

Lastly, you are in the cloud because you’re willing to change how you work. Don’t be afraid of changing your existing code. If you refactor and break something, change it back. The cloud makes this easy, so take advantage of that and keep improving your code.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | Comments Off on Reducing Cloud Cost

A Small LLM Fail

Another test with Copilot in SSMS (v22 P3) that didn’t go so well. This one surprised me.

This is part of a series of experiments with AI systems.

Looking for Known Data with Copilot

One of the things I wanted to do recently was do some checkdb checking of a system. As a result, I was looking for the last time this was run on a database. I decided to ask Copilot.

2025-10_0169

This made perfect sense, as this was a new restore, and I hadn’t run it. So I asked for the query.

2025-10_0170

This doesn’t work, but I’ve gotten used to pasting in errors and letting the LLM sort this out. So I did this.

2025-10_0177

OK better, but this still doesn’t work.

2025-10_0178

I apply this and run it, and it works, but doesn’t return data. I wouldn’t expect this to for this database, so I try to clue in the AI.

2025-10_0179

Seems wrong. On this page, DatabasePropertyEX, I see this:

2025-10_0180

Not sure why this doesn’t work well. I don’t see a way to change the model, so I’m not sure what’s being used or when it was trained, but I’d expect it to know what is in DatabasePropertyEX().

Prompt AI

Prompt AI was a little better, though not at first. I asked the question:

2025-10_0181

I got this:

2025-10_0183

I can’t select this code (submitted a bug), but this isn’t bad. The result of my next query failed as well.

2025-10_0184

At least I had a clue what to do. I started then with this:

2025-10_0185

I got the “with TableResults” added. I then asked it to modify this to find the last time DBCC CHECKDB ran. I got this:

2025-10_0187

Summary

To be fair I futzed with both of these a few times. An LLM isn’t deterministic, so I got different results, but I never got the correct result from Copilot. I did get this from PromptAI at one point, which does work.

2025-10_0188

GenAI’s are funny beasts. You definitely need to spend some time learning how to use them.

Posted in Blog | Tagged , , | Comments Off on A Small LLM Fail

T-SQL Tuesday #191 Round Up

I hosted this month, late as it turns out, but we still had a few entries. Here’s a look at the blogs people published.

First as always, Rob Farley writes about the complexity of string parsing, using TVFs. He also shows some of the performance implications of complex parsing. Thanks to Rob for reminding me to get the invite out.

Louis Davidson wrote about parsing HTML, which is definitely a challenge in T-SQL given the nature of the language and how embedded different tags can be. I’ve done this a little, and I prefer using Python to do this Winking smile

Courtney Woolum writes about working with the IMDB database and needing to parse comma separated data with STRING_SPLIT and APPLY.

Lucas Kartawidjaja brings us a look at a data outside SQL Server using the Log Parser, a free CLI tool from Microsoft that works well with data outside of SQL Server.

Andy Brownsword tries out the new RegEx functions in SQL Server 2025.

Hugo Kornelis hates intelligent keys because they store different types of data in the same column. He also shows some PARSENAME and CHARINDEX tricks.

Posted in Blog | Tagged , , | 1 Comment