Voice of the DBA

Author: way0utwest

The Book of Redgate: Evidence

We aren’t the only company that does this, but Redgate Software does try to be data driven. Across my 18 years, I’ve had plenty of people use evidence from customers, from usage data, from market research, and more to justify a decision.

I think Google and quite a few other companies have called this being “data-driven.”

The text on the next page continues the sentence:

not on people’s opinions, the volume of their voices or who they are. When the evidence changes, we are prepared to change our minds. We will thank, and never shoot, the messenger.

I will say that this has skewed a bit over time, as I find that evidence is subject to interpretation and I’ve certainly seen some people cherry picking evidence to support their decision. Sometimes by asking for certain evidence.

However, we did realize there were issues and have tried to correct. I was part of a yearlong project last year that impacted marketing, product, and engineering where we focused on getting more information from more customers, and especially being careful to get evidence from multiple sources, including different geographies. We had a bias to the UK, so we tried to correct for that, and I think we made some strides.

That being said, I haven’t seen us shoot or blame the messenger for bad news, though sometimes thanks are sometimes not as sincere as they could be. I understand, because contrary news tends to dampen enthusiasm.

I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.

August 21, 2026
Never is Not the Policy

Years ago I worked with a few developers and DBAs that were temp-table happy. As in they defaulted to using temp tables everywhere. This was in SQL Server 6.5, and tempdb was an issue with contention, sizing, and performance. I rewrote so many queries to remove temp tables for our clients that I banned them. I told other developers they could never use temp tables in their SQL code. They, of course, would try to submit code with temp tables in our VCS (Visual SourceSafe at the time), but an early, pre-automated CI/CD would notify me and I’d have the developer rewrite their code.

There were situations that didn’t perform well with a single query, and we did allow some temp tables. The point wasn’t the ban them entirely, but stop them from being a crutch for developers or a first choice. I wanted them to think about the problem first and try to solve it with SQL. If performance was an issue, then we’d look at a temp table.

Recently, I saw a post from Jeff Iannucci that noted there are settings you should never change. These were database-level or instance-level settings that he suggests you leave the defaults, or leave a specific setting chosen. An example of the latter is Page_verify set to checksum. The default in older databases, upgraded through different versions, can be none or torn page detection enabled. Fix that if you see it.

Examples of other settings are things like Auto Shrink and Auto Close, which shouldn’t be enabled. These types of settings should be left off, well, with a caveat from me. There are narrow places where you might want certain things turned on. For example, Auto Close isn’t the worst thing in the world, and there places where it makes sense. Dev servers with a large number of databases that aren’t often used might get help here in conserving resources. Same for production instances where a lot of older databases are kept around for archival, but we don’t want them open and consuming any resources without an explicit connection.

I don’t mind DBAs or developers having “never” as a policy for certain things, with the caveat that this isn’t a forever rule, but one that strongly sets a guideline that we don’t create exceptions for without a very good reason. Staffs change, internal knowledge is lost or narrowly shared, and often inexperience can creep into your environment. These strongly worded guidelines, even with “never” in them, help to keep everyone on the same path.

Strong opinions, loosely held. We change our minds and grant exceptions when there is evidence to do so.

Steve Jones

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

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

August 19, 2026
Accessing the Data API Builder MCP Server from VS Code
I recently started playing with the MCP Server for SQL Server, which is a part of the Data API Builder (DAB). I’m not sure why there wasn’t a separate piece of technology used, but I do think the DAB server is very useful, and I wish more people used it. Adding MCP to it makes some sense, as the REST and GRAPHQL endpoints can be disabled.

This post will look at a few things I did to get the MCP server working.

A Default for New Projects

By default, if you have v2.xx of the Data API Builder, when you create a new project (with dab init), you get this section in your json config file with the mcp entry.:
```
"mcp": {
   "enabled": true,
   "path": "/mcp"
}
```
This is the enabling of the MCP server. In my files, this was added below the “rest” and “graphql” sections under the “runtime” key. You can see this in a larger view of the file.

Once you add this, the MCP server should start up with DAB. The only indication I see in the logs is this message that the endpoints are enabled.

Adding an MCP Server to VS Code

My first experiment here was adding a server to VS Code. This isn’t a clear thing in the docs, to me, so I’ll tell you what worked for me. I already have some MCP servers in VS Code, so I really went through this process.

First, this is an http MCP server, and the URL is the DAB URL (for me: http://localhost:5000/mcp) that I’ll use to connect. I used the instructions in this VS Code article rather than the quickstart in the DAB docs.

In the VSCode command palette, I looked for the “MCP: Add Server” entry, as shown.

I then picked the http option:

Next, I enter the UL. I’ve pasted mine in here.

Give this a name. This isn’t clear in docs, but this is the name that you’ll use when starting this MCP server. I chose dab-northwind-mcp, which lets me know this corresponds to my config file and it’s a dab server.

Next we decide where this is available. I usually choose workspace, but the setting depends on what you doing with this server. I tend to aim to keep things more tightly configured, so that if I need it elsewhere, I can learn how to adjust that, or add this as an item for another workspace.

I then get my mcp.json file, which is the config file for the MCP servers in VS Code. These servers are a part of the “servers” key, as an sub-document below that. Each of these is a separate entry in JSOn. I essentially have two of the same here, the sql-northwind and dab-northwind-mcp point to the same server.

Starting the MCP Server

If you look at the image above, there’s a “start” link that VS Code adds as an annotation to the entry. You can click that. For me, I usually go back to the command palette and get to the “MCP: List Servers” entry.

Then I see a list of servers and I’ll select the one I want. In this case, that’s the dab-northwind-mcp one.

I see a few items. The configuration will open the mcp.json. It brings up output by default. I’ll pick “Start Server”

I can see in the output it starts. notice I have some errors, this is because the DAB server wasn’t running. I started it, and then went through the process above to get it restarted. You can see tools were discovered.

That’s it. The MCP server is active and running. I’ll do another post on how I can use this.
August 19, 2026
Republish: Going Big with SSDs

Let’s look back. This editorial was originally published on Aug 16, 2011, when SSDs weren’t as common as they are now. Can you even buy hard drives? What do you think about the world 15 years later?

I’m at the Fringe Festival with my wife today, so you get to re-read Going Big with SSDs.

August 17, 2026