John,

>First off, thanks for your insightful post. You and Bob are restoring my faith that an elevated discussion can occur. You provided exactly what I was asking for, and articulation of how and why a RV solved a particular problem.

OK...

>In your case, I see that you exerted a lot of effort to get RV's to work. And, it would appear that somewhere in your organization, the light has gone off with respect to what SP's can accomplish. I think it is important to note that my argument is based on SPT/SP being a technically better way to go. Whether it is a techncially feasible way to go is another issue. This is what I have been waiting for Mr. Ryan, or even Mr. Black for that matter to bring up.

I would say using SPT would have required just as much exertion. Now, entirely re-engineering the AS400 communication to use SPT and SP would have required a lot more exertion, but would probably pay off long term. SPT alone wouldn't have that pay-off for me.

IMO, I think Mr. Ryan is more concerned with statements like "SPT/SP is always a better way to go"...it has nothing to do with technical merits, just with language that sometimes gets used that fails to consider unique circumstances we all may encounter.

>However, just because something is not feasible, either because nobody in an organization knows how to do something or if it is something beyond ones control, that does not mean the technically non-feasible alternative is technically inferior. I think people are faced with a problem and RV's provide a way to get a job done. However, and as you have pointed out here, getting RV's require a lot of work. Often, it is more work than what should be required.

I would never say that RVs are technically superior to SPT, and I would never say SPTs are technically superior to RVs. What I would do is say what scenarios lend themselves to one way or the other, and let the developer work out which they think will work better for them. Most of all, I want folks to know that RV solutions are working for a lot of people with little or no ongoing maintenance. Same goes for SPT. The question in these cases is not which is better, because the proof is in the pudding, and the pudding has already been consumed.



I have no problem with the RV view designer, or the local view designer for that matter, because I use neither. I do everything in code, which is what I would also have to do if I were to use SPT. I still like having RVs so that for quick and dirty stuff I can MODI DATAB and quickly see where I am with my views. I suppose you could argue that in a sense I am already using psuedo-SPT, but technically I really am just using code-based RVs -- the best of both worlds. I have complete control (except for the ability to call stored procs, which I don't need) of my queries and updating, etc. while still being able to access the views in a meta-data fashion in the database designer.

I would argue that any developer who takes RVs to their utmost capability will end up eshewing the remote view designer rather quickly.

>This is how and why I can unequivocally say that RV's are technically inferior to using SPT directly. The RV designer is too buggy and cuts the developer off from the granuality of control a developer needs. With SPT, the developer can makes use of all the SQL Language features a backend has to offer. The use of SP's only makes the use of SPT that much better. If a method limits my control over things and another alternative exists that does not suffer from those limitations, and all other things being equal, the former method, by defintition, is technically inferior to the latter method.

I guess I would point to the solution of using code-based RVs, as I mention above. I can do any kind of SQL I wish that way, and still be able to see my RVs in the database designer and check in the DBC into VSS, etc. I suppose at a high enough level it all comes down to how you want to store the remote access meta-files and what front-ends you wish to use to develop that. I still consider what I use to be RVs...I build them in code, and the simple ones I can even use the designer when I want to... As usual, this discussion is about where to store functionality. In lieu of stored procedures, RVs and SPT are really the exact same thing when viewed in that light. Do you want to store your funcitonality in PRGs/VCXs that utilize SPT or do you want to write code that stores that functionality in a DBC? Is there really any difference?

As for your final conclusion, I think that virtually any scheme in VFP can be made workable once a developer spends a lot of time on it. I used to hate using local views. Ran into a roadblock (including the view designer) every which way I turned. But in the long run I figured them out and I think they are a nice solution for certain situations. Would you say that because of the worthless local view designer and some quirkiness to getting local views to work that local views are "technically inferior" to straight table access?

JoeK