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

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


>SPT alone wouldn't have that pay-off for me.

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.


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

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.



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

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.

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.

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.


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

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.

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.