>>
>No, you don't. You give a component those permissions. Or if you want to use RV from the client, you give the application the login information. IMO, giving the user _any_ database password is not as good as giving them _nothing_.
>>
>
>Regardless, the login used needs those permissions. Tell me, assuming we are working with components here, how would you move data from the component that has the RV to the client?

You have already raised this question, and Mike F answered it. But to review:

There are any number of methods, my current favorite being XML with inline schemas (XMLDATA). Others include objects, arrays, etc. I could also be using ADO with middle-tier generated SQL, and passing the RS objects back. This is not RVs, but any client generated SQL is the same concept.

>All of your arguments against RV with the security issue have been arguments against questionable practices that are not necessary with Remote Views. IMO, you still haven't given a single valid security argument against RV.
>>
>Fine... One of the main advantages to SP's has always been security. I will take my chances on being on that side of the fence. I have worked with both RV's and SP's. I would suggest you take a stab at working with SP's before shunning thier security benefits out of hand..

I am not shunning their security benefits. I am only arguing that similar security can be had with a correctly architected app that generates SQL in the middle tier.

>Cmon Erik, lets have an app showdown - RV's vs. SP's...
>
>Are you game?

That depends on what we are trying to show. If you want to show off how scalable SPs are in comparison to RVs, then the exercise would be useless. I conceded that to you long ago. If you would like to attempt to hack a SQL database that uses RVs for data access, then we can talk terms, because I am confident that such database could be made to be as secure* than your database that only uses SPs.

John, for me, this has never been an argument for RVs and against SPs. (I am currently working on a C/S app that will not use RVs anywhere). It has been an argument that sweeping statements like "flawed toolset" should not be made. The fact that a methodology exists that is sometimes (usually?) better suited to a job does not make RVs bad technology.

Footnotes :-)
* Theoretically, an application that takes the database login out of the user's hands could be made even more secure, because the user can only access the database through a component that is more flexible and has a much greater ability to interact with its environment than T-SQL does. The component could not only require app specific login information from the user, but also verify that the user is sitting at a specific machine, for example.