Can I Change a Primary Key Value? #SQLNewBlogger

I heard someone say recently that you can’t change a primary key value in a row. That’s not the case, so I decided to show a quick proof of that.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

The Scenario

Let’s set up a simple table with some data.

CREATE TABLE PKChangeTest (
ImportantNumber VARCHAR(20) NOT NULL CONSTRAINT PKChangeTestPK PRIMARY KEY
, CustomerName VARCHAR(50)
, StatusValue INT)
GO
INSERT dbo.PKChangeTest
   (ImportantNumber, CustomerName, StatusValue)
VALUES
   ('1234567', 'Steve', 1)
,  ('2345678', 'Andy', 1)
,  ('3456789', 'Brian', 1)
,  ('1235667', 'Leon', 1)
,  ('1265567', 'Dave', 1)
,  ('9914567', 'Bill', 1)
GO

If I look at this table, I have some unique numbers making up the PKs. If I select from the table, I can see the data.

2025-04_0117

Now, let’s change some data. I’ll change the PK values with a few statements. Then I’ll select from the table, and we will see things changed.

2025-04_0118

The ImportantNumber for both Bill and Steve have changed. These are PK modifications.

We can change a PK value. These are not set in stone once inserted.

SQL New Blogger

This is a short look at something that’s a myth among some people. When I heard someone say this, I knew I needed to prove this. The scenario took just about 5 minutes to set up (even without AI), and then it was another 10 minutes to structure and write this post.  I actually have 2 more ideas from this on things I can show to prove how PKs work and are malleable.

You can do the same thing. When you wonder about something, or hear something that isn’t true from others, prove it. And blog about it.

Unknown's avatar

About way0utwest

Editor, SQLServerCentral
This entry was posted in Blog and tagged , , . Bookmark the permalink.

1 Response to Can I Change a Primary Key Value? #SQLNewBlogger

  1. William's avatar William says:

    Exactly, primary keys only have to be unique they don’t have to be fixed. Foreign key dependencies can be dealt with by cascades.

    In addition using primary keys that mean something in the real world (rather than numbers or GUIDs) are a huge help in understanding the database and avoiding unnecessary joins.

    Like

Comments are closed.