>>You haven't said anything here except reiterating the argument.
>
>Really, read what I said. I made a distinction between business rules and action queries. I think business rules belong in the middle tier and action queries belong with the data. This gives you an additional layer of abstraction and IMO, helps to simplify application development.
>

You just restated the same thing again, without giving any real reasons, or at least without explaining the vague one you did give.

>>>So? I can delete all yours too. I just have to use the SPROC instead of SQL.
>
>Oh please! The chances of someone figuring out the name of the SP and what parameters to pass, and in what order is nearly impossible.

Oh yeah?

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

I just discovered the name, owner, and script of every sproc in your database.

> On the other hand, when you put permissons directly on a table, there is no stopping someone with an ad-hoc query program from screwing things up.

So have your Ad-hoc program routine connect with an account without permission. Or are you saying all ad-hoc is off limits?

>Also, in big shops where the DBA and developers are not always in synch, not allowing direct access to data can prevent a developer from accidently leaving off a where clause on a delete statement and wiping the table.

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

> Yep, because RV's require direct access to data, IMO they put your data at risk.

To a degree, I agree with you, I just don't think that the strategy leaves you as wide open as you are implying.


>>>No. John's valid point is that theory means little, real world numbers are the real deal.
>
>So, where are your real world numbers? At least I'm basing my argument on the countless number of articles I've read supporting this kind of framework.

As I said in my the last sentence of my previous post, I am only arguing with John that I am not convinced we've been presented with good evidence against remote views.

>What do you do when you need to add a user, recompile the application?

I am stating that you can have the application use a secure account for RV access. It doesn't have to be a different account for every user.

> If you don't want users to login, then use NT authentication. SQL Server gives you that option.

I know.

>I haven't seen any numbers, but a lot of experts are saying its the way to go. Even if there were no performance benefit, I would still continue to write SP driven applications. It just feels right.

It probably feels right because that's what you've been hearing and reading from a select group of people.

The most vocal adversary of RV's in favor of SPs in my view has been JVP, and from what I have seen some of JVP's gripes with RVs stem from attempting things that most people know not to do anyway (multi-table updates, etc). JVP also often implies that RVs must be used exclusively, and he doesn't address their use in conjunction with SPT/ SPs which IMO is probably the best way to go.

Please keep in mind that I am sort of playing the devil's advocate here to reinforce John R's assertion that there are too many people running around quoting (IMO, unproven) 'gospel'. My only argument here is that we should fully investigate before making sweeping statements.

I will not be surprised or humbled if anyone participating in these threads totally sways me with convincing evidence that we should not use Rv's it's just that I have not seen it yet.