Michael Swart amps up the complexity factor in his online deployment series:
There’s two things going on here (and one hidden thing):
-
The first two messages point out that a procedure is referencing the column
ColdRoomSensorNumber
with schemabinding. The reason it’s using schemabinding is because it’s a natively compiled stored procedure. And that tells me that the tableWarehouse.ColdRoomTemperatures
is an In-Memory table. That’s not all. I noticed another wrinkle. The procedure takes a table-valued parameter whose table type contains a column calledColdRoomSensorLabel
. We’re going to have to replace that too. Ugh. Part of me wanted to look for another example. -
The last message tells me that the table is a system versioned table. So there’s a corresponding archive table where history is maintained. That has to be dealt with too. Luckily Microsoft has a great article on Changing the Schema of a System-Versioned Temporal Table.
-
One last thing to worry about is a index on
ColdRoomSensorNumber
. That should be replaced with an index onColdRoomSensorLabel
. SSDT didn’t warn me about that because apparently, it can deal with that pretty nicely.
I’m glad that Michael went with a more complex example—it’s easy to tell this story with a simple procedure versioning, but in seeing a larger change, you can see the rhythm in the process—it’s all the same pattern of steps over and over.