When you find it necessary to update a primary key value as well as all matching foreign keys, then the entire design needs to be fixed.
It is tricky to cascade all the necessary foreign keys changes. It is a best practice to never update the primary key, and if you find it necessary, you should use a Surrogate Primary Key
, which is a key not derived from application data. As a result its value is unrelated to the business logic and never needs to change (and should be invisible to the end user). You can then update and display some other column.
for example:
BadUserTable
UserID varchar(20) primary key --user last name
other columns...
when you create many tables that have a FK to UserID, to track everything that the user has worked on, but that user then gets married and wants a ID to match their new last name, you are out of luck.
GoodUserTable
UserID int identity(1,1) primary key
UserLogin varchar(20)
other columns....
you now FK the Surrogate Primary Key to all the other tables, and display UserLogin when necessary, allow them to login using that value, and when they need to change it, you change it in one column of one row only.