>>>You just restated the same thing again, without giving any real reasons, or >>at least without explaining the vague one you did give.
>
>If you go back to the original post you'll see that John said the action queries I'm speaking of should be placed in the middle tier. I'm saying only business rules belong in the middle tier and action queries belong with the data. This is the additional layer of abstraction you go the SP route.
>

Yet again, restating the premise. This is getting sort of funny.


>>>Try this:
>
>>>oSQL = CREATEOBJECT("SQLDMO.SQLServer")
>>>oSQL.LoginSecure = .T.
>>>oSQL.Connect("CHARLIESSERVER")
>>>oData = oSQL.Databases("CharliesVerySecureDatabase")
>FOR EACH oProc IN oData.StoredProcedures
>>> ?oProc.Name, oProc.Owner
>>> ?oProc.Script
>>>ENDFOR
>
>How are they going to know the primary key value o pass to the SP? Its the job of the data class to generate the parms.

The client has to have access to the PK to operate normally anyway, I don't see how that's a hurdle.

> I've never done your example above, but I'm wondering whether you would need admin privledges to do so? Only the most trusted people get those priviledegs.

Not admin priveleges, but discovery priveleges to be sure. SQL allows pretty granular access to its resources, and access to SP discovery can be restricted, but my point is that this stuff is not as secret as you might think.

>>>So have your Ad-hoc program routine connect with an account without >>permission. Or are you saying all ad-hoc is off limits?
>
>All I'm saying is possibly a disgruntled employee or a developer can issue a delete all if they can access a table directly.

How are they going to access a table directly if they don't have the username and password for an account with these priveleges? In a three tier scenario, the login information is generally supplied by the middle tier (often on the server machine) anyway, so using RVs has exposed nothing to any user except someone with access to the source code of the business component. Even then you can hide access from the developer by setting SQL up to use NT authentication, and configuring your component to impersonate an NT account via its COM+ application, or through DCOMCNFG.

>>>It probably feels right because that's what you've been hearing and reading from a select group of people.
>
>It feels right because I have an application in production based on this framework and they scream! The performance through an ordinary modem is excellent. However, I have not written an application using RV's. I went directly to SP's.

Again, this is anecdotal evidence which does absolutely nothing to argue the anti-RV sentiment.