>>Over the last two weeks I've gone through a screening process with a company that provides several health care solutions. They're centered in San Diego and have offices across the U.S. They needed help in a variety of ways, went through some candidates whom they eventually didn't like, and then contacted me after someone there read my first book.
>>
>>I went through two screening processes, and one of the significant requirements was stored procedures. They absolutely will not accept any work that uses dynamic SQL from the application layer. ALL of their database work is done in stored procs - these are not ony company requirements but requirements from their clients as well. (They have a few side projects where they can use architecture, and still use them). I start work for them next week.
>>
>>Sure, it's all anecdotal. But now that another person has used anecdotes to make a point, it sounds like they've been "legalized".
>>
>>I'm sure as "God made little green apples" am not going to conduct a national survey to verify what I already know - the majority of SQL Server (and certainly Oracle) installations use stored procs as the norm.
>
>I have heard that SQL Server, unlike Oracle, does not compile views rather it has to run through the whole process (lack of a better way of putting it) therefore increasing the amount of time it takes to run the view. Is this true?

PMFJI, as an Oracle guy, can you tell me when I send an SQL command: "Select top 1 from sometable" does this command get sent to a stored procedure as in SQL Server?

If so, what happens when the client calls a stored procedure that executes the above command? Seems to me the above command would again be sent to the stored procedure meaning I've now doubled the stored procedure calls?