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

As a developer, you want total control over the process. Having control is far better than ceding control to a process that does it automatically.


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

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.

If however, I kept my naming convention of stored procedures constant accross the backends I may use, my client code can be the same.

Again, what you describe is more of an argument for keeping an API constant - programming to an interface, not an implementation.

Therefore, this is not an advantage of RV's..



[Bob]
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.

[JVP]
How is it that I am flaming you? How is it that I have assumed you are an idiot. If I thought you were an idiot, I would not bother with this discussion..

The fact is, you recommend RV's. I have a counter position. We are engaging in a debate/discussion. That said, don't take stuff personally.

Unfortunately, the arguments you put forth for RV's are not that strong. Please don't turn my posts around as personal attacks if you cannot make successful arguments for the use of RV's.

If you like RV's and the work for you, great. I am not suggesting you change your development practices. Rather, I am thowing issues out on the table that come from practical experience in order to make the development community that is considering the use of RV's more informed.


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

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

You are beginning to argue against yourself..



[Bob]
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?

No, I am not discussing the view designer. You are familar with the Grant Statement? The security model on server backends is very granular. Not only can you grant Select, Update, Delete, and Insert Rights against a table, you can grant rights on specific columns. You can also grant Exec rights on stored procs.

The most secure model is one where you DO NOT grant Select, Delete, Insert, and Update rights on any table. Rather, the only rights that exist are Exec rights on stored procedures - which you control....

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


[Bob]

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

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


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



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

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