Andrew and Marco: Actually, the reason to update those objects after the Table rename is because the objects themselves have changed to accommodate the "new" Table structure but that is not in place until the swap is made so we need to minimize the amount of time when calls can be made to the Procs, etc. (remember, the application is still running during the release) that would point to the incorrect structure and hence cause errors. This is also why we rename all of the objects that have no programmatic name-dependencies first (indexes, primary keys, foreign keys, constraints, Triggers) and swap the Tables at the very end (with the exception of then adding any Triggers that might exist). By doing the Table rename last in the "swap" script and then immediately updating the Procs, etc. we reduce that gap down to 1 or 2 seconds (and in some cases less than a second).

But to Marco's point about the objects having different IDs but yet the same name (i.e. stale references), this is why I have seen some people issue an "sp_recompile" on the "new" table after the rename in order to mark all dependent objects for recompile. I cannot say that I have ever personally seen an issue of a stale reference but doing the sp_recompile against the table is something that I used to do until I was told that it really didn't provide any benefit and I had no evidence to support the idea of stale references*. However, if stale references are provable then all you would need to do is add the "sp_recompile" to the bottom of the swap script.

Take care,

Solomon...

*Note: One might claim that I haven't seen stale references because I am, in fact, updating the objects after the rename anyway, possibly correcting the issue before it is noticeable. True, but I don't always update all objects. Sometimes Views and/or Procs use a subset of fields that are not changing so those objects don't need to be updated.