John..

>
>I have before... but if my arguments are compiled into a wiki, why repeat it over and over? Better to refer people to the Wiki where the arguments stand the test of time and there is less tendency for invective
>

I have read the wiki. Needless to say, I am not that impressed. Issues concerning security, performance, error/exception handling, and scaleability get short shrift. I would not hang my hat on too much of the info posted there. Of course, I am only referring to the specific topics on RV's vs. SPT/SP.

>As for Mr Black taking a personal shot at you; that may be your interpretation. My read is that SB was trying to provide "evidence" according to the normal scientific meaning to guide somebody who has decided that one technique is best and is now asking for evidence to support that. With respect, at first read that sounds like "junk Science"- decide the outcome then assemble the evidence to prove it. If you read Mr Black's post in that light, he is advocating a considered approach rather than just helping assemble "evidence".
>

While there is information on the wiki that is factual, a lot of it is conjecture, hearsay, and opinion. As such, it does not qualify as "evidence" in the objective sense. However, there are alot of glaring ommissions up there (the wiki). Having said that, whatever I say up here is simply my opinion; and therefore, is not evidence. What I do offer as evidence is my experience with successful project and discussions with people that have not had good experiences with RV's.

I am simply making an argument in favor of one technology over the other. Quite frankley, the arguments are pretty strong. If you want the wiki topic to have some value, take on those arguments in a light most favorable to RV's; if you can. I have opened the door to anybody to take these arguments on. If you feel strongly about RV's or feel that I am misguided, you should address the issues; if for no other reason, as a service to the community. After all, isn't the best developer and informed one?

It has been my experience that people shun SPT because of some perceived notion that it is hard. Nothing could be further from the truth. What gets hard is the SQL string concatenation mess that people put themselves through. This is where the beauty of stored procedures come into play. With SP's, regardless of whether you are using ADO/OLE-DB or SPT/ODBC, you don't need to get involved with messy data type conversions. With that in mind, people tend to shun SP's because they think it is complicated. Again, nothing could be further from the truth. If you have a modicum of understanding of SQL, you have all the primary knowledge you need to use SP's.

The only junk science I have come accross in this issue is that which involves RV's...< bg >.. And, appealing to the pseudo-authority, that which is the wiki, does not make the case any better. Take on the issues I enumerated in this thread.

Another point..what you bring up is the difference between theory and reality. You know what the difference is? Why theorhetical people are thinking about how to solve a problem, people grounded in reality have already taken the steps to actually solving the problem. My stance on this point is well documented here..

I don't waste alot of time thinking about different appraoches to solving a problem when the solution alread exists and is one that I have used. It is not desireable from an economic standpoint; either from my or my client's perspective. Of course, you always consider the totality of the circumstances. SPT has a presumptive advantage over RV's IMO. However, it is a rebuttable presumption; at least for the time being - but then again, maybe not. When it is all said and done, I get paid to deliver the best results as quick as possible.

Theorhetical people tend to solve $100 problems with $5,000 solutions. Results oriented people like to solve $100 with solutions that realize continuing economies of scale. As far as I am concerned, you can take about 90% of the theory and chuck it to the side of the road. Most people don't utilize the stuff anyway. Ultimately, when things need to get done, folks fall back on what they know works best. To me, getting the job done is far more interesting than a disertation on the design patterns I used. Quite frankley, I probably would not be able to break thing down into those terms anyway. Sure, there might be a delegation here or an observer there...so what!

Okay, I am going off on a rant here, let's cut it now...

To date, nobody has made a good case to choose RV's over SPT/SP in light of issues regarding security, performance, scaleability, maintenance, error and exception handling, and data/program independence. And, with a tool like Dataclas, that has the ease of RV's without the limitations and problems, I would dare say that the day of it still being a rebuttable presumption are over. Until the day comes when and if the Fox team decides to over-haul RV's, I consider the supieriority of SPT/SP a per se rule. If RV's get a massive over-haul, I will re-visit the problem.

Until then, I leave it to you to take your best shot!