>You cannot use SP's......

>SP's really make life alot easier... The T-SQL language is extremely powerful. Folks often run into problems when attempting large updates via a RV. How about those situations where you do need to work with large amounts of data? If you are tied to RV's, you need to bring that data down to a client - regardless of whether your client is the UI or a middle tier component. If you use SP's, your processing can be performed entirely on the server...

Ok

>In the beginning, when data sets are small, a problem does not exist.. However, when data begins to grow, the problems become evident. Folks see RV's as an easy way to C/S computing. I just took a call the other day from yet another company that found out the hard way that RV's don't scale.

I'm beginning to see the same problem. You make a good point about RV's being an easy way to enter into the C/S computing arena. Time to go to the next level.

>RV's do not fit in an n-Tier environment....

>If you are using RV's, you have no choice but to bind your UI/Data access logic together. In other words, you cannot open RV's in a middle tier component and make the data available to the client. SPT suffers from this as well. This is where ADO really comes into play...

This is big subject for me - one of which I'm currently struggling with in terms of redesigning my middle tier biz classes to support the handling of record sets. My problem is that I'm compelled to know all the possible combinations of how everything (ADO, XML, SQL Sever, blah, blah) interacts such that I can come up with the best schema possible. I don't think I'm alone in this struggle and any comments you have concerning such a comprehensive design would be much appreciated, John.