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

PMFJI - Was he arguing this fact? I thought the argument wasn't RV vs SPT, but where to use each. since one of the major tenants of C/S work is to minimize the datasets, using SPT in these cases would be a given.

>
>RV's don't scale....
>
>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 not sure why this is the case, since RV's are, by your own post, a SPT wrapper (even if it's only an incomplete one). The locking issue brought up can be fixed by a local DBC container and is even a issue with large two-tier applications.

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

If it's an issue with both, how can this be an argument against RV's?

>There are 5 points right there....
>
>So then, that is my position... I think the facts speak for themselves. Even if you don't consider tham facts, they do show a logical basis for conclusions on my part.
>

Interesting topic - not having much experience in large C/S applications myself, these are the kinds of threads that I look forward too.