It's anedoctical as you're here refering to an enteprise database with probaly very sensitive data and are trying extrpolate that to all db ussage which is far stretched to me. If you read my reply to your started thread (I did not receive your promised reply on), you'll see I did identify this as a case where you'd likely see more SP requirements.

As we are also in Healthcare and occasionally have to integrate with other SQL database (we provide our own SQL database and use HL7 primarely to integrate with other hospital systems), it is not our experience that dynamic SQL is forbidden, though for getting patient demographics it ussually is done through a SP because we do not have the knowledge and responsibility of the remote database. Therefore we lay the responsibility of interfacing in the hands of the DBA.


>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.