John

Of course RVs do not themselves provide the security. Nor do SPs. Of course it is the backend.

Yes, a SP can only do what a SP can do. That is the joy and the hurt of a SP.

No, you cannot do "delete *" just because you use a RV. If you can, security is set up incorrectly. As we have agreed that security is a backend concern, I am unsure why you believe such a backend snafu is exclusively a RV issue. It is a management issue- a booboo that is wrong whether it happens in a RV or a SP shop. Of course it may be fine if access is coming via a tier, eg with a web app.

>>If however, I gate access through a SP, I not only require a PK, I can require a token of some sort that signifies where the SQL is coming from. Each application can have its own token - known only to the application and the underlying procedures.<<

Sure. And in a RV system, each application can have a single "user" that has appropriate rights with user logins having *no* rights.

>>So with security, I guess we are talking about degrees of security. But for sure, the security argument is not "simply incorrect"...< s >...<<

It is simply incorrect to say that VFP Remote Access is "lousy" because of RV security.

>>When you have the right toolset - maintenance is not a problem...<<

No, whether it be SP or RV, this is true.

>>RV's are lousy - and I will stand by that argument.

Your "argument" is just a repetition.

>>The limitations of the designer are a good place to start.

Already covered. Also, have you looked at xCase?

>> RV's don't work in an n-tier environment.

??!! Where did you get that?

>>They don't work with SP's.

You are saying that RVs are not as good as SPs because they don't work with SPs. Whee, a circle.

>> Finally, they allow direct access to the base tables.

Allow direct access... to whom? To the application, yes. But so do SPs. A badly written application can damage data using SP just as easily as with RV. Neither should allow unfettered access to the user.

>>When you get involved in large-scale development, often, your app is just another consumer of the data. You don't get to make the rules. In your specific case, you may be allowed to make the rules.<<

I've already addressed this. You can say "I use SPs because the client wants me to", but unless the client is infallible you have no right to criticise others who do not have the same constraint.

>>The use of SP's is wide and is considered a best practice. I'll take comfort in that..<<

John, look at that lovely robe the Emperor is wearing.

Also, remember it is hard to be a leader and run with the herd. On this one you're running, running with the herd. Is that you?

Regards

JR