John,

>FWIW, a long time ago, I considered RV's. When I found glaring problems with their use; coupled with the overwhelming advantages of SPT/SP, I never looked back. Far too many people post messages and email me privately about the problems with RV's.

FWIW, a long time ago I considered RVs...I had trouble with them, but because I didn't know of a better way at the time, I stuck with them and figured out a way to overcome some of their problems while still liking the quick speed with which I could implement them.

I think Mr. Ryan is arguing that there will be occasions where RVs make sense. Yes, even more sense than SPT/SP. I am not saying the circumstances to cause this are smart, but I will say that they are "real-life", something you definitely appreciate (based on your posts about theory vs. real-life).

I am going to tell you about some real life. I develop apps against an AS/400 backend. I require the ability to query and send back data against AS/400 members. I am not going to get into what members are, but they sort of suck...at least to this table-oriented dude.

But I persevered. I figured out how to get members created, and then tried to figure out how to acccess data in those members. Figured out how to create ALIASes on the AS/400, and I was in business.

RVs seemed painful because of their static nature. Another AS/400 piece we have gets the dreaded "Base fields have changed..." almost weekly. I wished to avoid it, and I did. Because I am in a batch environment, I am able to create the ENTIRE DBC on the fly every time I need to send a batch of data up to the AS/400. I can then create my RVs at the same time, and have no worries about base fields changing.

Could I use updateable SPT? Sure. The problem is, the main table I update has 200 fields in it, and building commands to make the SPT updateable looked to be a pain. When I create my RVs I can generally just stick with SELECT * and that gets me by.

Were I to do it all again, I might give SPT a try. But RVs work for me in the same way that SPT/SP works for you. I can't write SPs. Our AS/400 is not openly accessible to me, and the AS/400 folks are just now getting around to realizing what SPs could do for us. Until then, SPT/SP simply can't work for us, while RVs get the job done famously.

So, all I am wondering (as is Mr. Ryan, I think) is, how can you unequivocably say that in all cases SPT/SP is the way to go? Many folks are in the boat of not having complete control over the front, back, and everything in between. They have to just work with what they are given and make it work. All the "well, it should have never been designed that way" arguments in the world aren't going to help (not saying you argued that, just trying to head off a potential direction). I turn to RV whenever I want quick and dirty access to AS/400 data, and whenever I have the option of completely creating the DBC on the fly. RVs kick ass in this realm, and it is a realm that is very real to me.



>If you decide to reply to this post, start technical reasons why RV's are either superior or as good as SPT/SP. If you do that, I will then address that issue. Then, you can address my response, and so on. That is the stuff that argument and debate is made of. If you do anything else, it will simply be a waste of time.

I have stated a case where RVs work better. Whether or not they are "technically superior" is unknown. Hell, I don't even know what that means. From what I have read, you don't really care either, you just want methodoligies that can get the job done. Here is one. I have delivered a case where RVs are as good, or better that SPT, and SPs are not even an option. Just thought I would add it to the record.

Thanks,
JoeK