Objects Dependent on Replaced Views

Views can be contained in other object definitions.

If the view that is replaced is contained in another view, the parent view is automatically recompiled when it is accessed.
If the number of columns in a view changes due to replacing, you may need to fix the definitions of other views and procedures that reference this view.
In this situation, the owner has replaced V1 with different number of columns and column names. P must also be replaced.
```
create view V1 as select C1 from T1 
create procedure P as select * from V1
```
```
create or replace V1 as select C1, C2 from T1 
```
In this next situation, the owner has replaced V2 by removing C2 from the definition. When P is executed, an error is raised, as C2 is no longer part of V2 . Because of this, P must be replaced.
```
create view V2 as select C1, C2 from T2 
create procedure P as select C2 from V2 
```
```
create or replace V2 as select C1 from T2  
```
Before you replace a view, run sp_depends to determine if there are any stored procedures or parent views that depend on the view you are replacing. If such stored procedures or parent views exist, replace the stored procedures or parent views as necessary after replacing the view.
Instead of triggers defined on the view are dropped when the view is replaced
Any PRS that are dependent on the replaced view will require a full refresh to restore them to a usable state. You can neither refresh them, nor use them for query rewrite until they are recompiled.