Dear John,

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

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.

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.


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

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

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

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.

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

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.

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


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

O.K. fact noted.>

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

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

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

Walter,