Walter..

>
I'm not argueing that remote views not SPT/SP are the way to go, but all to often I see prominent people make a statement that raises my hair. The statement "SPT / SP are always the best choice, or SPT / SP are superiour to RVs" is an unthoughtfull one IMO.
>

If given the choice between RV's or SPT/SP, I would choose the latter...always. That said, I understand it is not feasible to implement SP's, either because of the type of back-end or policy. This argument is one of technical merit, not business feasibility.

I have no problem with stating matter of factly that I would always choose one over the other, given the choice. Part of being able to say this involves having a framework with which to work. Second, I understand how SPT/SP, and ADO work. I couple this with the limitations that RV's impose, and thus, have reached the conclusion that SPT/SP is a better alternative than RV's, and thus, is an alternative that I would always choose given a choice.

There are those that would advocate that to be complete, one must always consider the alternatives. That is true, when there is a reason to consider the alternatives. The question then turns on when to consider the alteratives. I contend that day comes when a material change in the underlying premise of the alternative occurs. To date, no such event has occurred with RV's. While I am mindful that an alternative exists, there is no reason to consider that alternative until events lead me to undertake the analysis again. Until that day comes, more analysis would be inefficent and an EIF (Excercise in Futility).

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. This I believe is because there is a lack of resources out there today. To many, developing applications using this methodology, which is technically superior IMO, is difficult and hard to understand. My goal is to correct that issue.



>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. Also, if one asks me to hack into their database I'll create an connection and a RV for automaticly updating the datasource. If the circumstance are that I'm not allowed to make/change SPs on the server, I even don't have a choice. In highly datadriven applications where transparancy of backends is an issue, I doubt that SPT/SP are less troublesome than RVs.
>

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. 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. Different security models, data types, performance issues, etc. Simply put, if you are going to develop a client-server application, one cannot be back-end agnositic.

As for the assertions that SPT/SP are less troublesome than RV's, try implementing a union in a RV. Maybe you have not had to do this, but I have. What if you want to use a feature of the backend? How would you do this in a RV? The fact is, RV's attempt to homogenize something that is essentially heterogenous. Settling for the common demonator for the sake of simplicity and less variation comes at the expense embracing and working with the power that each backend has to offer.

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.

Ultimately, I am advocating an alternative way of dealing with a problem. It happens to be a way I actually develop applications. It is a methodology that has saved me countless hours of what would otherwise be wasted effort at mine and the client's expense.


>
Preferable/Feasible. If SPs's are not feasible for whatever reason, how can they be preferable ? Technically preferable ? Maybe, but sure not in all cases (transparency ? ease of use?)
>

Often, there are things that I want to do, that I know are a better way to go, but for one reason or another, they are not feasible.


>
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? Why not simply use SPT? Of course, if you do create the RV's in code, you can take more advantage of the full complement of SQL code that the backend has to offer. Of course, you would be cut off from making changes in the designer.

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'm realy curious about your 'scientific method' < vbg >. If everything you tried did not bring any advantages for RVs, don't mean there are not. Unless you can prove that every feature of what RVs bring are better implemented with SPT/SPs this statement is a non-argument.
>

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.

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

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

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


Remember, RV's are the wrapper built on top of SPT. 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. How about the menu builder, the report designer, the form designer, etc. All of these features solve many more problems than they solve. The same cannot be said of the RV designer.

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? What problem, inherent to SPT does the designer solve. SPT code is very easy and simple. If you want to manage updates through the cursor, yes, with SPT, you need to do a bunch of CursorSetProps. If on the other hand, you use SP's, you don't need to mess with a lot of CUrsorSetProps.

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.


>
From a 'front-end' transparency point of view, Remote views are far superior to SPT/SP IMO.
VFP does not care if you're hanlding a LOCAL or REMOTE view. The code is left (almost ?) unchanged when switching from local to remote databases. With SPT/SP you've at least to have some authorisation on the backend to add/change SPs and have to handle the updates from the VFP cursors to the backend. OTOH, I'm aware that you're saying that SPs serve more transparency on the serverside: If the structure of the database changes the SP can be changed to hide them from the front-end. If this is what you want, you're force to handle updates with SPs also.
>

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.


>
Of course, as with all things transparency might bring in some costs on performance in some cases.
>

Exactly my point. Often, the scaleability issues don't arise overnight. Rather, they creep up slowly. In 6-12 months, folks start to notice the applicaiton is not as chippy as it used to be. Now what do you do? The costs of re-engineering the app will almost certainly be as much as the original development costs. Yes, there are some things you can do to limp along. This all goes to my arguments about properly factoring in/not discounting the long-term needs and issues of an application. Many people that rely on RV's have found this one out the hard way. If however, the application was written using SPT's, believe it or not, re-engineering, while still a task, would not be as difficult. It would not be a cake-walk, but it would not be as difficult. And that is the bigger goal.



>>I would agree that if one had to pick a way to implement RV's, you have done it in the most palatible way I could think of. In the end, you are basically doing SPT.
>
>Could, you explain. I don't understand this point.

The gentleman implemented RV's in code. The point I was trying to make there, and here for that matter, is that if you are going to write code, you might as well use SPT.


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


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.

Good post Walter...thank you for participating!