I wrote a tool for this type of dependency refresh problem

it calculates the dependency graph for a group of changing objects

and generates the correct dependency-aware script to refresh the objects

it detects schemabound objects and correctly removes the schemabinding

after the objects are changed it replaces the schemabinding and recreates

any indexes (on views) that were silently dropped during the alter

because it performs all the operations in the correct order the fragile sys.depends in SQL 2005

stays intact (normally it deletes all child dependency records when a parent changes)

furthermore this approach avoids the nasty SQL problem of intermediate execution plans

being cached with stale column indices - this can result in columns jumping:

select [name], [address]

can end up returning

[name], [some other column]

if you alter objects in the wrong order

I have been curious for years how other SQL developers solve these issues - when I ask them

they just look blank ...