>>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.

>>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. 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.

>>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.

>>If this is a risk with developers, it's a risk with DBAs as well. I don't see >>the difference.

Good point. I once left a where clause off an update while on the phone with a customer and changed all the records, but I'm both the developer and DBA. I would guess in a lot of shops the two are seperate, and its much more likely the developer will make this mistake because he writing most of the queries.

>>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.