John,

Just a few comments, and then I need to get some work done... *grin*

>Precisely my point... All to often, the long-term needs of a project get greatly discounted to the detriment of the company.

Yes, sadly I think we all see that at a lot of points...OO, database normalization, proper QA... I would venture to say that time constraints and short-sightedness are the biggest differences between theory and practice.

>At least with SPT, the code that you would have off-loaded to SP's could have been implemented with SPT. You would not have had the same flexibility with RV's. You would have been in a better position. Then again, hindsight is always 20/20.

Yes, though with my program-based RVs, the logic would also be easy to offload. For me, it comes down to having the control over the textual code logic. Heck, in most cases I prefer PRG-based classes to VCX-based ones, even if there is some visual aspect involved. You can't beat good old text! The ultimate meta-data! *smile*

>I will stand behind the statement that SPT is preferable to RV's. SP's make SPT that much better. Whether SP's are feasible ,that is another issue. However, feasibility does not diminish the technical superiority of the combination of SPT/SP.

>Would you agree that there are a lot of problems with the RV designer, and those deficiencies could rationally lead one to conclude that if SPT does not suffer from the limitations imposed by the RV designer, SPT is a techncially superior alternative.

I would call the RV view designer icing on the cake. Even if it doesn't work, I still have cake. Comparing text-based RVs to SPT (obviously text-based since no designer exists) gives the edge to SPT because of the ability to call SPs. However, many of our remote views are simple and static, so being able to access those RVs via the designer can be a time-saver. I know it is a mish-mash, but most project run the gamut from very simple (perhaps even read-only) views to complex, ever-changing, updateable views. RVs offer the ability to do simple stuff (I wouldn't call it trivial, because even the largest projects are going to have some simpler views) and complicated stuff well, only falling down when it comes to calling SPs. With SPs out of the picture, that give the edge to RVs for my scenario.

>Whether one agrees or disagrees, I don't care. However, I think some are insinuating that I don't have a rational basis for making this claim. I have employed the scientific method on this issue and it has lead me to this conclusion. I have tried hard to find a case for RV's, only to have the premise defeated. Technically superior alternative don't succumb so easily.

In my opinion, no one has said you aren't rational or don't have a basis for your claim. It is the claim itself that folks are having trouble with. To say that for any situation SPT/SP always has the technical edge is a precarious stance. As always, you have to choose the right tool for the job based on all real-world circumstances. The bottom line is that people would probably just like to hear that you see their point, but for situations in your experience, SPT/SP has the edge. I know that is the gist of what you have always been saying, but sometimes your language obscures that complimentary tone. I will further state that you are not the only one using a conversation-defeating tone -- it takes two to tango. *smile*

>I will agree that for down and dirty work, RV's provide a quick and easy way to get data into VFP. With that in mind, I don't usually associate the phrase quick and dirty with a techncially appealing alternative.

Agreed, but sometime quick-and-dirty is all you need. Yes, you could argue that such uses are "trivial", but they are uses nonetheless.

>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. IN your scenario, you could actually reference stored procs unions, and other things the RV designer won't let you do. However, if you ever tried to do a modi view, you would have problems. So with that said, trying referencing a stored procedure in your RV code. It will work! However, you cannot modify the view.

Hm, that's a good point. Actually, in my final implementation I have thrown some SPT in, mainly for the creation of members and the creation of aliases. My objects are such a mix of RVs and SPT that it would be hard to draw the line between them.

>The meta data argument is also a good one in favor of RV's. If there is one product I would like to see developed, it was a meta-data manager for folks who opt to use SPT instead. Who knows, maybe I will write one.

Excellent idea...I am wondering how one would go about turning SPT logic into meta-data...SPT strikes me as being very "conversational" in its use, but then again, I am probably just not coding with it in a modular fashion. Aren't classes that expose SPT functionality meta-data enough? Not in the strictest sense of meta-data, but generically, just a simple DEFINE CLASS could be sonsidered meta-data...

>You have put forth a good argument. I don't by into RV's. Still, you have put forth a rational and techncially based argument. And for that, I thank you again.

Well, and my argument displays that for the final solution I used the best of both worlds, and quickly ditched the weakest link in RVs (the designer). Once we switch to more SP usage, I am sure my coding will evolve to the point where the RV stuff is basically just like SPT anyway...

Thanks for the discussion!

JoeK