The facing page has this quote: “We admire people who get stuff done. While there’s a place for planning, thinking and process it is better to try – and try well – and fail than not to try at all.”
This is an approach I use in lots of my life. Not always, but I do try to get things done, and make a strong effort in doing so. I ask the kids I coach to do the same. The effort is what matters; it’s more important than the outcome. The outcomes matter, but we can accept mistakes.
This is one of those values I think ought to be more prominently displayed and discussed, in most organizations.
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.
This is a short post on how to rename a column in a SQL Server table.
Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.
I Typo’d a Name
I was testing something recently and created this table:
CREATE TABLE BinaryData
(
BinaryDataID INT NOT NULL
CONSTRAINT BinaryDataPK PRIMARY KEY,
Emoji VARBINARY(16),
UserPic VARBINARY(MAX),
BinaryTexet VARBINARY(250)
)
GO
I didn’t realize at first that the last column was BinaryTexet and not BinaryText. I added data, wrote a few queries, and had done some testing. Using SQL Prompt is great, but it hid my silly mistake. As I went to send this code elsewhere, I realized my mistake.
I could have dropped the table, created a new one with the right name, saved the data or moved it, and done more, but that’s a lot of work. It also might cause me issues with the dependencies from other code. Not this column name, as any dependencies have to be fixed, but I could have other FKs or things that I don’t want to recreate.
I could, I mean I use version control and tools to make refactoring easy, but everything is more complex than renaming this column.
Renames
In SQL Server, we have an sp_rename function to handle this. I had hoped there was a way with ALTER TABLE ALTER COLUMN, but while I can change types, nulls, etc., I can’t change the name.
SQL is such a weird language.
Certainly for SQL Server. PostgreSQL and Oracle have an alter table rename column a to b in the DDL. We have a function. Vote for a cleanup here.
In any case, the syntax is: sp_rename <objname>, <newname>,<objtype>.
For me, the code is easy. I qualify out the old name:
One really interesting thing is that if I fully qualify things, I definitely don’t get what I want. Be careful here. Another reason why an ALTER TABLE RENAME COLUMN syntax should exist.
This was a short post I made after realizing I made a mistake. I took about 10 minutes to experiment with renames, and another 5 searching to be sure I couldn’t rename things.
In the experiment, I realized how I could break things, so I captured that mistake (and fixed it), and pointed it out. Showcase how you learn. For bonus points, write a blog where you use AI to help you do this.
A customer was testing Redgate Data Modeler and complained that it auto-generated PK names. I had to test and discover if I could make things better, and I could. This post shows how.
I can easily add a new Table to my diagram. I’ll click the New Table icon in the menu.
When I click in the design surface, I get a new table.
On the right, I see the table properties. I’ll need to fill these in.
Let’s change the name and add a few columns to this design. Note that for the first column I checked the PK box. This will be my primary key.
These are fine for now. Let’s now add adjust the PK.
Setting the Primary Key Constraint Name
If I click the three dots next to the PK check, I get a lot of properties for the column, not the PK.
I need to go below the columns. Notice the sections below the column area. One of these is for the Primary Key.
If I expand this, I can see the name field and columns. This was blank, but I typed in a name that makes sense to me. I could add columns as well here.
Checking the SQL
If I click the Generate SQL button from the top menu, I get a dialog.
I click the Save button, which will save this to the file specified. I’ve set this in my project before (which is another post), but I am trying to save to a single file for my code that updates.
When I open this code, here is the relevant part of the file. Note that my PK is named appropriately.
What happens if I don’t do that? I added another table, marked a PK, and this is what I see. First, my table (there is nothing set under the PK tab):
The SQL code shows a standard similar to mine, but different. I think a lot of people use the underscores, so I’m not surprised this is the setting.
Not bad, but not what I want.
Summary
The Redgate Data Modeler is a basic tool for now, but it does let you set a specific PK name if you want to enforce a standard. This can’t be set as a default, but I’ve submitted a feature request to change this.
At least I can customize what I want as I build something.
Give Redgate Data Modeler a try and see if it helps you and your team get a handle on your database.
With the AI push being everywhere, Redgate is no exception. We’ve been getting requests, demands, suggestions, and more about how to add AI into our products and help developers and DBAs be more productive.
One of the areas we’ve started to add some AI is in Flyway Desktop (FWD), with a few features designed to help reduce the cognitive load and context switches needed while developing code, and help users better understand what changes they’re making in their systems. This post looks at one of those changes, which is in preview (as of Jan, 2026).
I’ve been working with Flyway and Flyway Desktop for work more and more as we transition from older SSMS plugins to the standalone tool. This series looks at some tips I’ve gotten along the way.
Understanding Deployment Scripts
In Flyway, we call the deployment scripts “migration scripts”, but they are the same thing. These are scripts that are changing, altering, or evolving our database schema in some way. New or altered objects, various schema items, and more.
When a developer creates a migration script, they often do this close to the time they are making the changes in development. Not always, but I find a lot of customers change something, test it, and then make the migration script. Guidance for a lot of customers is to keep the migration scripts simple and easy. For example, here’s one I have that creates a simple table. If you look in the image on v23, which says “Create Product Table” in the description, that is what it does.
If I click on this line, I see the script shown below the name (V23__Create Product Table.sql). The new thing just below in this image is that an AI summary is being generated.
In a few seconds, this changes. I get the summary of the table. In this case, it says I have a new table with some columns.
If I expand this with the drop-down on the right, I see the full summary. This includes telling me a PK is being created, which is good info. I could look through the code, but the settings, the PRINT statements and more make this harder than it should be.
What about a more complex script? If I pick a different one, such as V24__Removed Territories and Region tables and related constraints and procedures, I get an OK description that lets me know a few things are being changed. I wish this had a little more detail in it, such as the tables on which FKs are being dropped, and maybe a list.
Let me create a whole new set of objects. In this case, I’ve added some discount features in a bunch of tables. Here is the list of objects I added to the migration script.
When I generate the migration script and then click on it in the Migration Scripts tab, I see this description.
That’s an interesting description, as I see that there are territory and customer tables, which I’d forgotten I added. I was working on them and added them, but hadn’t committed them. I added the discount stuff (3 tables and a view) in a dev session today, and then selected everything to save and include in a migration script.
This is one of those areas where the summary helps me remember what’s in here, and in this case, I’d want to delete this script and re-generate it with a different set of object changes. Then a second migration script with other changes.
Enabling AI Features in Flyway
This is a preview feature as of Jan 5, 2026 as I write this. To get this in your FWD, your organization needs to have enabled AI features in your portal. I’m just a member, but whoever is an admin for your Redgate products would find it here.
In FWD, you need to look at the Preview Features item under the config menu.
In this area, you can enable or disable features as needed. I see these marked as Red-gate only, but I think they are supposed to be released to some customers by this time. It’s likely I need to upgrade my FWD, which I’ll do when I have time.
Once you do this, you should start seeing some AI stuff with the purple/pink shaded area and the sparkle icon that we’re all seeing everywhere.
Summary
This post shows one of the Flyway AI features that we’re adding to help you deal with the chaos and complexity of database development in your environment. This features tries to summarize the details in your migration script and provide you a summary.
This isn’t perfect, but as you look at scripts, it fairly quickly gives you a look at what’s included without you having to read all the code. You should double check the code and be sure it’s what you expect, but if you’re looking through a few scripts for a particular change or impact, this might help save you time.
There is a limit to the amount of stuff we send to the LLM to summarize. I can’t remember (or find) the limit, but very large scripts aren’t summarized, and you’ll see a message to that effect.
This feature is documented, but we are likely to enhance and change it a bit, so all feedback is welcome. If your organization doesn’t want you using AI, and you could share some schema from a migration script, I’d be happy to test it for you and see what summary is produced and send it back to you. Ping me on X/LinkedIn/BlueSky if you want.
Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today. It works for SQL Server, Oracle, PostgreSQL and nearly 50 other platforms.
