To answer your concerns Flavio, I agree the creation order of views needs to be explicit due to dependencies if one view does depend on another, but the order of refreshing views will not matter as long as all those views have already been created prior to running of the PRefreshViews SP.

To answer your query, Stored Procedures automatically get recompiled if an underlying object gets changed. "Recomplication of a Stored Procedure occurs if an underlying table used by the stored procedure changes, and also the first time a stored procedure is run after Microsoft SQL Server is restarted." http://msdn.microsoft.com/en-us/library/ms190439.aspx (I can't find any info on functions reagrding recompiling, so I don't think it's possible or required??? correct me if i'm wrong).

To answer your question Gary, our organisation has not pin pointed one specific issue one of our customers has had with our application due to a view not being refreshed, mainly because it might not have happened at all, but also because our development team have been unaware of the need to refresh views until very recently, and wouldn't of recognised a view not being refreshed to be the cause of an unusual bug... But after some education, have been made aware of the potential issue, and believe it to be best practice to ensure our views are refreshed after any data model changes have occured. Better safe than sorry I reckon! But thanks Flavio for highlighting some of your issues you've experienced when modifying underlying objects, it shows it's worth implementing...

Thanks guys for your comments and questions.

Cameron