Very interesting, Michael. Thanks for the information.

So many aspects to so much of what we use these days! Wonder how many people can keep up with it **ALL**???

Cheers,

Jim N

>>You say "the server view is faster, because the view code is precompiled".
>
>It's my understanding that Microsoft SQL Server does not precompile views. The way I understand it, SQL Server parses the view, checking for syntax errors and then stored the text in the SYSOBJECTS table. When you access the view by referencing it in another query, SQL Server takes the view definition, combines it with your query, and then optimizes and compiles the resultant mutant query.
>
>
>>While I have no reason at all to dispute that fact, I *do* wonder about just how much faster the fact that it is precompiled actually makes it.
>
>The Sept. 1999 issue of SQL Server mag (a great mag BTW) has an article by Kalen Delaney that discusses caching of query plans. She lists some example parse and compile times. For this query:
>
>SELECT COUNT(*) FROM northwind..products WHERE categoryid BETWEEN 1 AND 9
>
>The resultant parse and compile time is listed as:
>
>SQL Server parse and compile time:
> CPU time = 11 ms, elapsed time = 20 ms.
>
>
>> I mean, how long can a compile of a SQL statement really take and what percentage would that time be of the whole?
>
>I'm guessing that most of the time is really in the optimization phase, not parse or compile. SQL Server's optimizer is so strong, if you were to turn it loose, it could actually spend more time optimizing the query than running it.
>
>-Mike