OK then.... you are in agreement with the problems of the view designer...

Onto RV's themselves....

It is a lot easier to fix a SP than a RV. Here is a good question... if you agree that there are issues with the RV designer, why would you bother with RV's? I understand that you can create these items in code. However, if you are going to bypass the RV Designer, why not just use straight SQL Pass Through?

Again, the RV - not the designer - is an WORK IN PROCESS. At best, it is an imcomplete wrapper around SPT. If it were complete, you would be able to employ all of the SQL constructs you can with T-SQL, including Exec calls to stored procs.. You can create a RV based on a stored proc IN CODE. However, you can never modify these items in the RV designer. And with that in mind, it still begs the question of why you would bother with RV's...

Tell me Bob, how much T-SQL have you done? When you really take a look at what T-SQL offers, at least from a SQL language standpoint, you realize how deficient VFP's implementation of SQL is. Keep in mind that my comments are in the context of C/S computing. My comments DO NOT extend to situations where you are working with VFP data only...

Onto some specific deficencies with RV's:


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


SQL is rendered from the client...

This has many implications. From a security standpoint, the entire table must me made available. With SP's, you can make your security model very granular. If you allow SQL to be rendered from the client, any fool can then latch onto your server and issue a query that brings a server to its knees...


High Schema/Application dependence...

Often, when you make schema changes in SQL, regardless of whether you use the new field(s) directly or indirectly, your RV's are broken. This is not an absolute rule, but it occurs often enough to be painful. SP's buffer you from these sorts of issues....


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.

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


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.

Rod and I have a pretty big VFP C/S app, probably the biggest out there to back these claims up...

Could you employ the same sort of analysis of why you beleive RV's are the correct choice?????





>>>>Sure, you could. I don't think there is any right way to do it.
>>
>>OK, I'll ask this question:
>>
>>With the obvious deficiencies that RV's possess and the pitfalls they open you up to, why would you consider using RV's?
>>
>>This can turn out to be a good debate...
>>
>>OK, your turn...Make your case...
>
>Well, I have to say that you haven't made your case to me that there are 'obvious deficiencis and pitfalls' to using the rv.
>
>Most all I have heard from you, and also Rod is that if you change the schema your RV's are dead. This is actually a View Designer issue, and if you don't use a SELECT * and you add a column to the remote table, the view will still work fine. As I said in another message, changing a column in a table which is access by a SP or a RV causes the same result, you have to modify the query.
>
>I have also heard alot of other problems with the view designer... Hey, I'll give you that, the VD is limited. However, the view designer is just a visual interface to a view... you don't need to use it.
>
>The issue with DBC locks is easily solved by private DBCs.
>
>So, you want me to defend deficiencis and pitfalls that I don't consider 'facts in evidence'.
>
>BOb