Hi Kevin,

>Brandon gave a terrific response on views. His point #3 is perhaps the biggest of all. Big conversions of legacy databases to new databases will often use views in the transition phase, and even beyond that. You'll also find them often in reporting applications.
>
>Generally, what's stored in a view is just the SQL query itself, not the data.
>
>Just wanted to add two additional things
>
>First, in SQL Server (don't know about Oracle), you can't pass parameters to views. There are workarounds (sometimes using table-valued functions), though they tend to be a bit involved.


You typically do not need to pass parameters the way you do in VFP views, because the view itself does not execute the way it does in VFP. If you do a

SELECT * FROM MyView WHERE Field1 = Value1 AND Field2 = Value2

the SQL Server optimizer will combine the SQL of the view with the SQL of the statement above and will optimize it as a whole. In this case Value1 and Value2 can be regarded as the parameters


>Second, there's one instance where a view actually "stores" data - a materialized view. It almost sounds like a contradiction in terms. It's not terribly common, but some people use them for fast retrieval of aggregated data. There are several requirements for a materialized view, so you won't seem them often.

Yep, there typically is a high price to pay for materialized views. First of all, you need the Enterprise version of SQL server ($), and second, materialized views take up storage space and the insert, updates and deleted on the underlying tables with cause extra I/O to update the materialized view. In many cases it might be better alternatives such as building a data warehouse solution.

Walter,