John..

You bring up some good points. As I said, one must always take stock of the circumstances. And, one must consider when it is prudent to change course. At the same time, I don't advocate needless tinkering for the sake of doing so.

As for the technical argument, let's remember this thread started with a guy who advocates SPT and wants arguments to support that position. His position happens to be in line with mine. As such, I gave him what are probably air-tight technical arguments. To date, nobody has taken those issues on. So with that said, the technical merits of what I advocate have not been dis-proven.

As for whether other folks are wrong for using RV's, I don't think I have said that. What is right or wrong is not the issue. Rather, the issue is whether on balance, one approach is better than the other. I have seen many cases where a person has taken less than optimal means to end up with the intended result. In business, and even the law at times, the ends justifying the means can be a compelling argument. Certainly, during these trying times, it is more true now than ever. If somebody gets the desired results and his superiors are happy, who am I to say he is "wrong". I many not agree with the means, but nonetheless, I cannot argue with the ends achieved. Is the long-term benefits mortgaged and compromised for a short-term gain? Perhaps, but only time will tell.

In this case, a person came here looking for ammunition to support his POV. I guess I am getting molded into that way of thinking, to be a person's advocate, to put forth the best argument for his side. That is what the guy came here for and that is what I delivered. The last thing he needed was debate on whether his POV was correct. As I said, the Wiki topic is pretty neutral, still leaving it up to the person to decide. And, some of the most compelling arguments against RV's are missing.

I did read your comments. You cite the ability partially refresh large cursors with the Refresh() Function. I don't find that compelling. First, one should have have large cursors of data in a C/S app. Second, there is a lot of work involved in what RV's do behind the scenes - you don't get that for free.

As far as performance is concerned, whether RV's are as fast as SP's is not the issue. I have seen fast client-side rendered SQL statements and I have seen slow SP's. It is a matter of how things are engineered. I will tell you that on balance, a stored procedure offers more opportunities to improve performance. For example, in a stored proc, you can produce a number of intermediate result sets before returning the final result set. With RV's, you would have to return all of the result sets and perform the munging on the client. As far as the posted benchmarks are concerned, unless they were done under controlled/real conditions, they are suspect.

There is a section that list items that may favor the use of RV's. My favorite is this one:

Using remote views requires less knowledge of the back-end syntax.

The fallacy of course is that if you are developing a C/S app, one needs to be knowledgeable about the back-end. As far as the syntax is concerned, it is SQL that is being passed to the the backend. That syntax is being generated on the client. If one is tasked with building a C/S s/he needs to know and understand all aspects of the system: both the client and the server.

As far as this subject matter is concerned, the wiki topics you reference don't bring much in the way of substantive information to the table. On that score, we shall simply agree to disagree.






>Dear John
>
>I use RVs for the reasons I cite in the Wiki. I do not ALWAYS use RVs- of course RVs are sometimes unsuitable. Examples or experience of RV unsuitability do not mean RVs are entirely bad.
>
>You say I should repeat it all here. I suppose I could cut-and-paste it here... but why not just refer people to the wiki so the repository grows and we all learn, including those too busy to read threads every day?
>
>FWIW, SB does not claim Wiki is an "authority"; he casts it as a community and user generated data repository. If it is "deficient" then one hopes that people in the know will fix that.
>
>>>I don't waste alot of time thinking about different appraoches to solving a problem when the solution alread exists and is one that I have used. It is not desireable from an economic standpoint; either from my or my client's perspective<<
>
>In terms of "efficiency", questioning and looking for better ways has proven efficient, effective and immensely profitable for my company. We are proud to be inventors and entrepreneurs. That you are not, does not mean you are "bad", its just a different approach that may be just as successful for you.
>
>Which I guess is my point. If you have found a way that works really well for you, of course you should pursue that proven formula. But if people come up with a different way, you cannot say they are always wrong. Perhaps their circumstances are different or perhaps there is something you have not fully understood. Even the mighty MS bows to this creed- look how they clasped the Internet when it became clear that "their way" was not the best.
>
>In summary, on this issue it seems to me that you "protesteth too much".
>
>Regards
>
>JR