Ken,

I'm not going to get into your pointed statements to Erik. I will say that I agree with Erik's open-mindedness, and some of his points about using RVs (namely, the fact of using them as a middle-tier enabler) make a lot of sense.

>I haven't bothered to look at all the messages in the thread, but Why SP over RV? Here are some simple answers:
>
>1 - no VFP DB - solves many distribution and upgrade headaches
>2 - RV is NOTHING BUT A WRAPPER for SPT and SPT is better served calling SP
>3 - SP afford you easier migration to different front ends
>4 - more secure because you can lock tables down and deal with access through SP rights.
>5 - Less netework traffic
>6 - Inherently faster due to caching
>7 - My SP based solution will walk all over your RV based one in every aspect.

I would agree with point 1. SPs are clean because they require nothing from the application other than a calling mechanism...of course, this is why they become a hindrance when I need different backend...

About 2. IMO, you can't fault a methodology for being a wrapper. Being a wrapper is what most abstrations (like ADO, for one) do! OO is all about wrappers and such making various bits of code reusable! The advantage of a wrapper is that it can wrap multiple things, thereby making it more useful than having to do the same thing over and over again (if that is your need).

About 3. Yes, various front-ends are easier. What if my needs require that I use one front-end and three backends? Two backends and 50 front ends? Ten backends and 2 front-ends? The combinations are endless. That's why I think the concept of a middle layer is a nice approach. It acts as a wrapper for multiple backends while being a single point of access for various front-ends.

About 4. I don't know a lot about security, but surely any procedural data access can be locked down, whether through middle-tier COM objects, backend-SPs, or application logic?

I think you would have to be correct about 5. In fact, for a lot of the evidence saying speed is much better, the network gains may be the main reason for them.

About 6. Yes, I think performance is better for SPs, but then again, it should be. Any more-specific solution is going to be faster than an abstraction (like RVs).

About 7. Interesting tone. "Walk all over" in what aspect? If you are coming back to performance, then fine. When I ask you to move your backend, I will be "walking all over" your app for the duration it takes for you to port your SPs. What is the point here? It is like saying I can use a hammer to walk all over a screwdriver to pound nails. Well, yeah, but pardon me for not being impressed.

Time for lunch!

JoeK