John,

>COnsultants, IMO, are paid to deliver solutions in the most efficent and cost effective manner they can. If it turns out that RV's are the way to do this in a particular circumstance, so be it. However, just has people have accused me of turning a blind eye to RV's, developers I believe, don't consider the combination of SPT/SP.

O.k. so, you're basicly telling us that SPT/SP is a powerfull and more flexible alternatve for remote views ? Yes, I agree.

>>I'm sure you can think of some exceptions where RVs might be the more logical choice. If I think about transparancy of backends it seem easier to use RV than SPT/SP.


>Transparency of backends is a myth. The fact is, it is a derilectionof duty on the part of a developer to not make the best use of a backend as he can. For example, if I had to deploy an application on SQL Server and Oracle, I would be crazy to not use features in Oracle that in the long run, would be better, for the sake of keeping a "transparent" backend.

I think this depends on the nature of the product. Most of my projects don't handle very large amounts of data and because of the nature they never will. Now I stand on the point to extend some of these application to the client/server arena, because some issues of low bandwidth/replication. One option is to replace all local views with remote views and leave the front end intact for the most part. The SPT/SPs would certainly give me more headaches than remote views in this case.

However when I think of al the reports that have to be generated SPT/SP is the clear winner here.

I think about transparancy here because i've got a lot of clients for the same products and the client may ask, We've got an ORACLE server running, is it possible to use this one in stead of purchasing SQL-server ? while another customer for the same software might prefer SQL-server. Transparancy is in my case far more important than performance.

>Each backend is different and has its own set of characteristics. To think that disparate backends can be treated transparently for applications that have to scale in a variety of ways is an over-simplification of the real issues that exist.

What about applications that don't have to scale ? For example I have some application that registers data from employees of dutch jails. Since dutch jails do not employ more than 1200 people in general it makes no use to make it scale to 120.000 employees. The approx max amount of data in the database can be easely calculated since they will not hold data for more than 10 years. With this in mind you can safely test your performance.

>With this in mind, if you or anybody else works with each backend in a homogenous way that allows you to use RV's, good for you. I can tell you that applications that have even moderate complexity or have to scale don't fare as well. And, if you do find yourself in a performance tuning mode, being able to work with the language directly, as opposed to having to be forced into constraints imposed by the RV designer, is a far more appealing alternative to me.

Good points for SPT/SP, but I never doubted this.

>The visual RV designer has lots of problems, but this has not have anything to do with RVs themselves. You can always create them in code which allows you to fully use the potentials of RVs. Remember you've got a lot of programming to do with SPT/SP also.

>If you are going to go to the trouble of creating them in code, why do you bother with them?

Creating RVs in code is not that hard, and even quite straitforward. Creating a RV takes me far less time than writing a moderate complex SQL SELECT statement.

>IMO, if you are going to bypass the visual designer all-together, there is no reason to use RV's. And as you say, the RV designer has lots of problems.

I disagree, I even prefer to design them in code, or desing the most part in the view designer or eview save them to a prg and adjust that what is needed.

>That is where I think you are wrong. All I have to do is find a few issues with the RV designer to make this conclusion. But since you asked, the analysis goes something like this: (for the record, at this point, one can leave SP's out of the analysis, at least in a direct sense.)


>1.
>Q. Can I do everything in SPT that I can do in RV's?
>A. Yes.

Prove the YES.

Example: You don't have permissions to create SPs. How would you create an updateble view in the least amount of time possible ?

Example: Upsize the your tables and local views. Without changing a single line of code in the front end, make it work.

Example: You encounter different back-ends, of which your knowledge might fall short, for your product, how would you implement updateble views ?

>2.
>Q. Can I do everything in RV's that I can do in SPT?
>A. No.

No argue from me.

>Q. Is SPT inherently more complex than RV's?
>A. No.

No argue from me.

>Q. Do RV's have the advantage of being in a managed and meta-data driven env.?
>A. Yes.
>
>5.
>Q. Can the previous advantage of RV's be simulated in a SPT env.?
>A. Yes.

Prove it.

>Remember, RV's are the wrapper built on top of SPT.

And that might exacly the strenght, because it hides complexity, type casting, and SQL dialect of the backend. I might not be interested in what back-end is attached as long as its capable of handling all I need.

>It is an extra layer that limits your flexibility. IMO, anytime you have a situation like this, the burden of justification shifts to the extra layer. i.e., the extra layer needs to solve a problem. For example, take Fox 2.x for example. Did you use the screen builder or did you still hand-code screens? In that case, the screen builder solved way more problems that it created. And, if you wanted, you could still go in and hack the SPR.

No, I hacked the Genscrn.prg.

>How about the menu builder ;

Nope, My own datadriven menu solution.

>the report designer ;

Crystal Reports, far more powerfull.

>the form designer ;

If I need something that can't be done (e.g.: placing custom headers in grids) I hack the forms.

>The same cannot be said of the RV designer.

I technique I frequently use, is to design the view to the point as is possible, save them to a PRG, and manually adjust it to fit my needs. The PRG is save with the project so, I could easely adjust it when underlying tables have changed.

>A techncially compelling reason for RV's would be a solution to a problem that is inherent to SPT. This would be its "killer application". Every piece of software or feature of software that is useful has at least 1 killer application. For VFP, it is the database application. Nobody does it better than VFP. What is the killer application of the RV designer?

Ease of use ! I can't think of a more simple way of creating an updateble remote view.

>The record is replete with chinks in the RV armour. I have made a good technical argument here that you and others have required me to defend. That is the only reason why I write these posts, because people respond and reply, asking me to defend the position. I don't waste time with saying I think SPT is better because I think SPT is better. Rather, I put forth objective and bona-fide evidence for why the alternative is not appealing. The art of argument and debate is founded on rebutting the other side. The Pro-RV side has put forth the contention that RV's have a presumptive advantage with respect to back-end transparancey, ease of updates, simplicity, etc. I contend it is a rebuttable resumption and have offered arguments to not only refute those presumptions, but to make a few presumptions of my own with respect to SPT. To date, a serious attempt at refuting those presumptions has not been made.

This is all your perception on the issue. You've failed to convince me (and others), that SPT is always the way to go. Transparancy is more important to me than anything else. Performance, is not an issue because not in all cases will this be a serious limitation. Maintainability: not in my case, since the database is exclusively designed for the application, it will not be a problem at all.

It leaves me that because RVs are more data driven and transparent it will be the more logical choice for me in certain circumstances.

>It is clear that you have stated an advantage of RV's, I concede that. However, when you are dealing with local data, one cannot apply the same rules to remote data. There is a scaleablity issue there. You cannot treat remote data in the same manner as you treat local data. To illustrate:

>Let's say you have 100K customer records and you have immediate access to them in a local/data local view scenario. Now, you want to upsize those local views to remote views? Will you see a big difference in performance? I think you will.
>While you contend that data transparency, the ability to treat local and remote data the same and/or to treat disparate backends the same, is a myth because of the inherent issues of scalability.

I see the point of scalability, and I'm fully aware that there is a huge gap between handling local data in a VFP database with its visible and directly usable indices and the remote data with its invisible internal scheme of metadata and indices. The point i'm trying to stress is that we don't all write C/S applications with large amounts of data with a huge potential scaling problem.

>Again, I think that the discussion about RV has nothing to do with the poor featured view designer, like local views don't either. If the View designer would be enhanced in such manner we could do everything what we can do in code now, would this mean you would reconsider your standpoint on remote views ???

>Then perhaps a good technical argument for you to take up is "Why do you use RV's if you bypass the designer?"

Transparancy, ease of use, and having them stored in a database container so they're accesable within two or three clicks from the project manager.

>And yes, if the RV designer was over-hauled, I would re-consider my position as then, it would be appropriate, fair, and just to re-evaluate. That has always been my position.

So, basicly your whole disliking of RVs is based on the view designer. I come to the conclusion that you have a different definition of RVs than I have (and maybe others). Maybe our differences in opinion are less than we think.

Walter,

>Good post Walter...thank you for participating!

Thank you.