>Well James, you'll get no help from me. I'm also a big fan of all data access going through stored procedures.
>
>First, for each ad-hoc query that is sent to the server, the server must parse, optimize, compile, and execute the query. This might not sound like a big deal, but it's enough for MS to build features into SQL Server to cache these types of queries (If you're interested, lookup sp_executesql in the BOL). Technically, stored procedures have gone through the parse, optimize, compile, execute processing before they're used. This is not true in all implementations though. For instance, with SQL Server 7.0, a stored procedure is parsed when it's created. It's optimized and compiled the first time it's called.
>
>Second, stored procedures add an additional layer that provides a mechanism that can be used for security. You can prevent users from directly accessing the table, requiring them to only go through your stored procedures.
>
>Also, stored procedures provide a mechanism to hide table structures and structure changes if/when they occur.
>
>As for SPT vs. views, I'm also a fan of SPT. It's more flexible than views, and view parameters and views are basically a wrapper for SPT.
>
>-Mike

Mike,

I agree that stored procedures are faster, and I understand SQL Server's caching mechanism, but you can't beat a view for quickly accessing data. Also, a view can be part of VFP's dataenvironment. Beyond that a remote view can be optimized using SQL prepare. Building an entire application justs by using stored procedures just doesn't make sence to me.