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

Because SPT doesn't create a read-write buffered cursor which automatically creates the UPDATE statements when you tableupdate() it. With SPT you would have to write your own code to build the UPDATE statements comparing old values to current to see if there was a change.

This is the main advantage to using RV's.

>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

This is an incorrect asumtion. The RV is designed to use ANSI Standard SQL to enable you to use the same RVs with SQL Server, Interbase, Sybase, Oracle. If the RV generated T-SQL Specific SQL they would not be very usefull.

>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

Not as much as I like... but, you seem to be writting your message from that standpoint that I feel all acess should use RV's.

>the context of C/S computing. My comments DO NOT extend to situations where >you are working with VFP data only...

Thanks for assuming up front that I am an idiot. You could at least wait till I say something that has to do with local data before flaming me for it. Of course, when we talk about RV's we generally don't talk about VFP data.

>You cannot use SP's......

If you are saying you can not run a SP with a remote view, I agree. Yet, I don't see how that is relevant.

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

Once again, you seem to be assuming that I am advocating RV's for 100% of data access, I never said that. RV's place is to populate your basic CRUD (create, retrieve, update, delete) form. They work well in this position.

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

You lost me... but, I think you are discussing the View Designer again. Are you saying that if I don't have access to three fields in a table, I can't use an RV? Or, that I can't use the View Designer?

Also, how can 'any fool' send SQL to a server? I assume you mean any fool that has access to the server. You are implying here that you can't use the SQL Server model when you use RVs? Is that what you are saying?

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

Once again, you are taling about the VD here. Changing the schemea where it would not break the query doesn't hurt the RV. Also, this only breaks the VD if you have used Select * in your quesry... since the VD compares the fields in the DBC with the fields in the table and sees a difference. But, if you force the VD to not use the *, when you open the view again, even if you had added a field to the table, it will still open and be fine. And, even if not, so what... THIS IS A VIEW DESIGNER ISSUE!!!

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

They where using them WRONG then. RV's have to be used for a CRUD form where you are bring a single or small set of records to the front end. Just because people abuse them (no parameters) doesn't mean they don't scale. I wouldn't use SPT to bring 10,000 records accross either.


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

Now your getting crazy. I can open an RV in the middle tier. From there getting it to the front end I have many choices. I could populate a data object and convert it to XML, or I could just convert the cursor to XML. However, I admit, if the font end wanted, or my middle tier was designed to pass an ADO recordset, I would use ADO to query the data. Actually, I could just take the SQL out of the view and send it to the SQL Server in the ADO command object to get my RS.

Again John, I never said RV was the way 100% of the time. Where you have said NEVER use RV's.

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

All I am saying is, RV's have a place in some aps. I didn't say they are God's answer to remote data access.

I also know that some people try to treat remote views as a table, never use parameters and wonder why their ap runs like an old dog with three legs. This doesn't mean RV's don't scale.. it means that the programmer has ignored one of the most basic rules of C/s which is to limit the amount of data you move over the wire.

BOb