>[Bob]
>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.
>
>[JVP]
>Buffering is not an advantage of RV's. I can get buffering from ADO and cursor created by SPT. As for creating code, tools are available to build the statements for you. They are native to Enterprise Manager. And, if you prefer, it is a fairly trivial task to build your own. Hey, we build builders don't we?
>

You have said several time not to use the buffering in ADO because it is flakey and to use the command object to do updates. But then you'd need to if you were running SPs.

>[Bob]
>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.
>
>[JVP]
>Using the same RV's for any backend... Ah... if it were REALLY that easy. So, your position is regardless of any advantage a specific backend may have, you would not take advantage of those features for the same of keeping everything generic for the sake of using RV's...
>

No... I didn't say that... there are certainly times when you want to use SQL Specific to the back end... in this case with SPT or SP.

>The fact is, the idea of 1 RV for every backend is a myth. There are differences amongst the different back-ends, and you need to account for those differences.
>

True enough... but this is true of your SP's too, it doesn't make using RV's wrong.

>[Bob]
>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.
>
>[JVP]
>SP's are relevant because the use of SP's is a central part of my position... Or, have you not been following that closely? < s >....
>

No, you said a 'problem with RV's' is that you can't run SP's with them. I am saying using RV's doesn't preclude you from also using SP's. Since you can run the SP with SQLExec() (or ADO if you prefer) even if you use RV's also.

>[Bob]
>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.
>
>[JVP]
>Other than Inserts, Updates, Deletes, and Queries, what else does one do with data? That said, you are in effect advocating the use of RV's for 100% of your data-related activities.
>

Yes, but there is a difference between getting a customer record to display on a form the user edits, and posting a GL. Although they both basically Retrieve and Update data.

>[Bob]
>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?
>
>[JVP]
>If you allow Select rights, what is to stop a user from issuing ad-hoc queries against a server. These queries might select 100's of thousands of rows, or they may be cartesian products, etc. Also, there may be access to senstitive data that would otherwise be prevented through the use of stored procedures....
>

If 'any' fool user has rights to run an SP that queries data, can they get data with the SP as easily as running a select? Remember, locks on keep the honest, honest.

>[JVP]
>Again, we agree in the buggy nature of the view designer. My question, one that you have not answered yet, is why you would use RV's if the VD is so buggy? Why not use SPT??
>

Well, isn't that what a view is? Why not use the RV to store the SQL, open the connection, send SQL to the back end, populate a Cursor, set the propeties of the cursor, maintain a buffer of old values, create the update code for you, sent the update code to the back end. Now I can modify my 'spt' queries without having to go edit code.

>[Bob]
>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.
>
>[JVP]
>To get the data from the middle tier to the UI, you need to use something other than a RV. You are making this a 2-step process. Again I ask, why bother?
>
>Futher in your response here, it sounds like you agree with me to some extent. However, you need to realize that if you take the Select def of your RV for the query you will run with ADO, that requires SELECT permissions on the underlying table....
>
True, but the fact that you can't use RV's or send SELECT to the backend isn't a 'problem' with RV's. Perhaps in the next version an RV would be able to run an SP, but not today.

Anyway... your method has it's place, as does using RV's as does ADO, as does local data access. I wouldn't advocate using ADO in a standalone VFP ap using local data, that doesn't mean I would dismiss ADO out of hand.

>[Bob]
>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.
>
>[JVP]
>Again, other than inserts, updates, deletes, and queries, what else does one do with data???
>

It's not what you are doing with the data, its the volume of data you are dealing with. Querying one record to display in a form for a user to modify, then updating it is the use for RV's. Summarizing 15 years of wheather data of a data warehouse to analyze and forcast is perhaps not something you would do with RV's. But, in both cases aren't you just querying data?


>[Bob]
>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.
>
>[JVP]
>Well, we have some agreement here. However, limiting the amount of data over the wire is only 1 aspect of the equation. There are many other important aspects that RV's DONT support...

...the for those aspects don't use RV's. But, I think you have to evaluate what you are doing, what the requirements of the project are. I can't think you believe that one size fits all.

BOb