Re: Application Role

From: Paul (paul.nerie@1902software.com)
Date: 06/18/02 

From: "Paul" <paul.nerie@1902software.com>
Date: Tue, 18 Jun 2002 00:52:19 -0700

Hi,

I just got into this thing, tried it, and found that it
does not work. As far as I experimented with it anyway.
It works fine with the Query analyzer and a VB app, but I
still was able to import data in excel and create a new
Access project with the mdb.

I guess there's no point in pursuing any further
according to your suggestion.

Paul

>-----Original Message-----
>Application roles were designed to let an application
connect to a
>specific database and have a set of permissions applied
just for that
>role. For example, you might have an Excel app that
retrieves data
>into a spread*** and is used by 100 people, not all of
whom are in
>the same windows group or have a login to SQLS. So to
avoid having to
>administer all those logins, you create an approle, a
SQLS login for
>it to use, and in your Excel code you log on using your
special login
>and activate the application role, retrieve the data,
and get out.
>
>In reality approles don't work well in any application
where you don't
>have total programmatic control over an ADO connection
object (i.e.,
>Access or bound data controls or the DE in VB) because
OLE DB
>connection pooling keeps getting in the way. IMO for the
most part
>you're probaly better off with standard database roles.
>
>-- Mary
>MCW Technologies
>http://www.mcwtech.com
>
>On Mon, 17 Jun 2002 13:52:05 -0700, "Eric"
<eremington@datapex.com>
>wrote:
>
>>Can someone point me in the direction or some resources
>>on the net of a good reason to use an application role.
>>Seeing that the connection needs to have a server login
>>first, what is the benefit of using an app role instead
>>of an "App_User" login and "App_user" user for the db.
>>The applications I write would only allow certain
>>functionality limited to the query stamped out in code
>>and the connection for that user. Am I missing
something?
>>
>>Thanks,
>
>.
>

Quantcast