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

What if you delete a field or change the name of a field? The RV breaks. I agree that adding fields does not present that much of a problem. Nonetheless, there are other types of transactions that cause problems...

<
If I am using SPs, I have to update at least one and probably two or three SPs to reflect the change,
<

True, but what if you use the field in multiple RV's? I am not saying that you won't have to do some work with SP's. However, to say that you save work by using RV's is far from being a certainty...

<
as well as change the code in the data access class that builds the parameter list, and recompile the object.
<

Not if you use DataClas. We never recompile objects with dataclas, regardless of our schema changes. Sure, our UI has to be changed. As far as our middle-tier goes, that almost never changes. The only time it changes is when business rules change.

When we make a change using DataClas, there are two basic changes that are possible, one that is required. The first deals with the SP's. They have to be in sync with the underlying table. Using a backend like SQL Server, this is a fairly easy issue to deal with - especially if you are in a remote environment. The second one is optional. This deals with the UI. If you make schema changes on the back-end, you may or may not immediately make the change on the UI. With RV's - because they are bound to the UI, you don't have a choice here - you need to make the change.

<
How is that more manageable?
<

If you use dataclas, or do something on that level, it is extremely managable.

<
I know that you can build wizards and the like to generate your SPs and data access classes, but the steps are still required.
<

Out wizards generate most of the standard SP's. You still have some work to do. It is never 100% automatic. I don't think anybody expects that. As for data access classes, we don't have wizards for that. Then again, the API for a data controller in data clas is very simple... If you wanted, you could create one data access class for your entire application. The following class defintion would work for any table in your database:

Define Class cusSystemSetupDataController As cusOleDataServer
  cDatabaseConnectionName = "XX"
  cSprocPrefix = "XXSP_" && stored procedure prefix.
Enddefine

When you create an instance of the class, you pass in the name of the table. Of course, this would not be practical in reality since you have different business rules for different tables. However, if you elected to but your rules in SP's, you could in fact create one data class for your entire app..


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

If you use connection sharing, you can use SPT and SP's. If you go that route, that means you are using RV's for nothing more than the visual designer and display purposes. To which I say, "Why bother?" Also, if you use RV's, at least once, you have to issue a Select... from the client. If you stick with SP's and bypass RV's - you can eliminate this issue..

As for 90% of all cases, you are providing a hard number that you really cannot substantiate. I would disagree that 90% of the apps out there are "trivial" in nature.


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

It always depends on the environment... As far as having an account that can create stored procs - as a developer I have that. The regular using logging in however, has an account that can only do 2 things:

1. access the database
2. run selected stored procedures



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

Our middle-tier does not have the password. The middle tier is totally generic. If your middle-tier items have this type of information - I would suggest you rethink your design...If you want to instantiate our data classes, you need to provide a login and password. Once you are logged in, your table-specific dataclasses - in conjunction with our generic COM Component act as an interface to the underlying stored procedures....



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

You feel you are not qualified to speak on the how to leverage a platform such as SQL Server or Oracle? Yet, you are attempting to engage me in a discussion on RV's v. SP's??????

I will remember this comment...


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

I think we would agree it is the developer, not the tool...



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

Interesting how you bring up the real world. Again, you have admitted earlier that you are not qualified to comment on how to fully leverage the SQL-Server platform. Therefore, when it comes to helping people understand these issues, I don't you are the best one to do that. I say this because SQL and SP's are central to the issue...


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

Again, you said earlier that you are not qualified to comment on how to fully leverage the SQL platform. Therefore, I would add that "it pains me to see people echoing some party lines with out understadning why one technology may be better than the other." I used quotes because for the most part, these are your words...

You cannot look at the RV/SP issue in a vaccuum. You need to understand what the backend provides.



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

Erik, you need to differentiate what you think should be the case as opposed to how things really are. And as you admitted earlier, you don't have alot of experience in the corporate world and working with DBA's. How you think things should be is usually irrelevant - unless of course you are also the DBA. But often, this is not the case....

Properly designed systems take into account security and abstraction. That said, your statement here does not make sense...


I think this discussion has run its useful course...

< JVP >