>Pefomance is not the only issue. Much of it is managibility.

I agree, and to me, this is one point where RVs have at least one advantage: when I add a field to a backend table, If I am using RVs to update that table, I only have to update the view definition. If I am using SPs, I have to update at least one and probably two or three SPs to reflect the change, as well as change the code in the data access class that builds the parameter list, and recompile the object. How is that more manageable? I know that you can build wizards and the like to generate your SPs and data access classes, but the steps are still required.

>Stored procs allow more control - better error trapping and handling.

Ok, error trapping I'll give you. But the "more control" argument implies that if you use RVs, you can't use SPT or SPs, which is not true. For 90% of all cases, all you need is the Add/Update/Delete functionality that a basic RV gives you. In that last 10% of cases, you are still free to use SPT or SPs.

>>Uh, how about requiring a valid account for the connection? If the username and password are encrypted and compiled into the exe, there's your protection. The security argument is completely invalid, because the same issues apply to both techniques.
>>
>
>This is where Charlie's argument wins Erik. How hard is it to get a valid account - other than sa. And unfortuantely, in many situations, getting the sa password requires no great feat of strength either.

Well, I suppose this depends on the environment. Having surely worked in more corporate environments dealing with DBAs than I have, you have more experience here. But it seems to me like if the DBA was kind enough to give you an account that can create stored procedures, then he would probably give you an account that has table access.

>With the use of stored procs, I could care less whether you have the password in the query analyzer or not. The deal is, you only have access to the procs - and the procs define what you can do. The security argument is not invalid. Talk to any DBA with his salary/hourly rate.

Consider this- by creating SPs in the database, you have defined a secure interface to that database. By accessing the database only through a middle tier object that holds an encrypted password, you have defined a secure interface to the database. The only difference I see is where you wrote your SQL: in the middle or in the back.

Note: I am only addressing the alleged security issue here- I am purposefully ignoring the scalability argument until later.

>Underlying these procedures is the same contacts table. These procedures however, provide a logical view. Can I do this with RV's or SPT on the client? Of course I can. However, what if I need to now serve up part of my data to another app, perhaps the web. If I took the stored procedure approach, a signficant portion of my business/data logic is already to go as it is UI-indepdendent.

This is not a SP/RV issue, it is a C/S vs n-tier issue. I can gain the same advantage by encapsulating my logic in a data tier (which could use RVs or SPs), and using that object from various front ends.

>The issue is not whether it can be done on the client v. the database. You can put the logic anywhere. The question is where it should go.

I have never argued that it should go on the client. Only that it's not out of place in the middle tier.

> The limits may not kick in today or tomorrow. If you are using SQL Server, Oracle, etc, why not leverage the platform to the fullest extent?

This could very well be a valid point, and one that I am not qualified to speak on.

>As far as VFP is concerned, the streets are littered with many failed C/S projects that tried to use RV's or that were "over-thought".

Well, the streets are littered with projects that failed attempting to use all sorts of technology. In most cases, it was the competence of the developer(s), and not the technology at fault. I have seen you make this same argument in response to anecdotal evidence of failed VB projects.

For all those listening in (I copied a bunch of you)- please understand that I am not promoting Remote Views over Stored Procedures. I have taken it upon myself to argue this issue so that the real issues at hand can be discussed and understood. I have a lot of faith in the testimony of those here who have expressed that Stored Procedures worked for them where Remote Views would not.

But it pains me to see people echoing party lines without really understanding why one technology might be better than the other (it is evident from this thread that at least a couple don't). This is not just true of the RV/SP issue, but of many technological issues where gospel seems to be carved out of one or a few people's (possibly unqualified) opinions, and the masses follow blindly without investigating themselves or even wondering where the proof is.

I dove in on this issue because it's one that I am striving to fully grok myself. If you're wondering about my current stance on the issue, here it is:

Stored Procedures are a best practice because: in many cases it is difficult to tell the future needs of a system in terms of scalability. Stored Procedures hold a notable performance advantage over Remote Views because they are precompiled. Though this advantage is probably worthless in 50-75% of most Client/Server applications, it only becomes more valuable as the application scales. This is a very important need in light of the internet age, where a database can go from 10 simultaneous users to 100 or 1000 by flipping a switch to launch a website. This reason, and this reason only, are why I think that stored procedures are the way to go.

The issues of security and abstraction advantages still hold little water with me, because they shouldn't be an issue at all with a properly designed system in the first place. As for security: using remote views simply moves the line of defense to the middle tier. The same is true of abstraction- the arguments being given for abstraction are against putting logic in the UI, which a good system should never do anyway. Putting all of this logic in a data access tier nets you the same advantages in abstraction and portability as does putting the logic in the backend itself.

HOWEVER- I don't think that Remote Views are a bad technology. They are a very convenient wrapper around all of the SQL needed to perform updates on a variety of remote data stores. For quick and dirty data access, they are definitely the fastest and easiest way to go, and if you're not concerned with the issues outlined above, then they should remain a viable choice for you. If you choose to use remote views, you might occasionally find yourself with the need to access that data in a more granular way, but have no fear- YOU STILL HAVE THE OPTION TO USE STORED PROCEDURES OR SQL PASSTHROUGH FOR THOSE CASES.

And this concludes the longest message I have ever written on the UT. :-)