应用程序角色与标准角色有以下区别： 应用程序角色不包含成员。 不能将 Microsoft Windows NT® 4.0 或 Windows® 2000 组、用户和角色添加到应用程序角色；当通过特定的应用程序为用户连接激活应用程序角色时，将获得该应用程序角色的权限。用户之所以与应用程序角色关联，是由于用户能够运行激活该角色的应用程序，而不是因为其是角色成员。默认情况下，应用程序角色是非活动的，需要用密码激活。 应用程序角色不使用标准权限。 当一个应用程序角色被该应用程序激活以用于连接时，连接会在连接期间永久地失去数据库中所有用来登录的权限、用户帐户、其它组或数据库角色。连接获得与数据库的应用程序角色相关联的权限，应用程序角色存在于该数据库中。因为应用程序角色只能应用于它们所存在的数据库中，所以连接只能通过授予其它数据库中 guest 用户帐户的权限，获得对另一个数据库的访问。因此，如果数据库中没有 guest 用户帐户，则连接无法获得对该数据库的访问。如果 guest 用户帐户确实存在于数据库中，但是访问对象的权限没有显式地授予 guest，则无论是谁创建了对象，连接都不能访问该对象。用户从应用程序角色中获得的权限一直有效，直到连接从 SQL Server 退出为止。若要确保可以执行应用程序的所有函数，连接必须在连接期间失去应用于登录和用户帐户或所有数据库中的其它组或数据库角色的默认权限，并获得与应用程序角色相关联的权限。例如，如果应用程序必须访问通常拒绝用户访问的表，则应废除对该用户拒绝的访问权限，以使用户能够成功使用该应用程序。应用程序角色通过临时挂起用户的默认权限并只对他们指派应用程序角色的权限而克服任何与用户的默认权限发生的冲突。应用程序角色允许应用程序（而不是 SQL Server）接管验证用户身份的责任。但是，SQL Server 在应用程序访问数据库时仍需对其进行验证，因此应用程序必须提供密码，因为没有其它方法可以验证应用程序。如果不需要对数据库进行特殊访问，则不需要授予用户和 Windows NT 4.0 或 Windows 2000 组任何权限，因为所有权限都可以由它们用来访问数据库的应用程序指派。在这种环境下，假设对应用程序的访问是安全的，则在系统范围内统一使用指派给应用程序角色的密码是可能的。有几个选项可用于管理应用程序角色密码而无须将其硬编码到应用程序中。例如，可以使用存储在注册表（或 SQL Server 数据库）中的加密键，只有应用程序有加密键的解密代码。应用程序读取键，对其进行解密，并使用其值设置应用程序角色。如果使用多协议 Net-Library，则含有密码的网络数据包也可以被加密。另外，当角色被激活时，可以在发送到 SQL Server 实例前将密码加密。如果应用程序用户使用 Windows 身份验证模式连接到 SQL Server 实例，则在使用应用程序时，可以使用应用程序角色设置 Windows NT 4.0 或 Windows 2000 用户在数据库中拥有的权限。这种方法使得当用户使用应用程序时，对用户帐户的 Windows NT 4.0 或 Windows 2000 审核及对用户权限的控制容易维护。如果使用 SQL Server 身份验证，并且不要求审核用户在数据库中的访问，则应用程序可以更容易地使用预定义的 SQL Server 登录连接到 SQL Server 实例。例如，订单输入应用程序验证运行该应用程序的用户，然后用相同的 OrderEntry 登录连接到 SQL Server 实例。所有连接都使用同一登录，相关权限授予该登录。一块学习！我是丛帮助中摘的！不好意思！
不能将 Microsoft Windows NT® 4.0 或 Windows® 2000 组、用户和角色添加到应用程序角色；当通过特定的应用程序为用户连接激活应用程序角色时，将获得该应用程序角色的权限。用户之所以与应用程序角色关联，是由于用户能够运行激活该角色的应用程序，而不是因为其是角色成员。默认情况下，应用程序角色是非活动的，需要用密码激活。
应用程序角色不使用标准权限。
当一个应用程序角色被该应用程序激活以用于连接时，连接会在连接期间永久地失去数据库中所有用来登录的权限、用户帐户、其它组或数据库角色。连接获得与数据库的应用程序角色相关联的权限，应用程序角色存在于该数据库中。因为应用程序角色只能应用于它们所存在的数据库中，所以连接只能通过授予其它数据库中 guest 用户帐户的权限，获得对另一个数据库的访问。因此，如果数据库中没有 guest 用户帐户，则连接无法获得对该数据库的访问。如果 guest 用户帐户确实存在于数据库中，但是访问对象的权限没有显式地授予 guest，则无论是谁创建了对象，连接都不能访问该对象。用户从应用程序角色中获得的权限一直有效，直到连接从 SQL Server 退出为止。若要确保可以执行应用程序的所有函数，连接必须在连接期间失去应用于登录和用户帐户或所有数据库中的其它组或数据库角色的默认权限，并获得与应用程序角色相关联的权限。例如，如果应用程序必须访问通常拒绝用户访问的表，则应废除对该用户拒绝的访问权限，以使用户能够成功使用该应用程序。应用程序角色通过临时挂起用户的默认权限并只对他们指派应用程序角色的权限而克服任何与用户的默认权限发生的冲突。应用程序角色允许应用程序（而不是 SQL Server）接管验证用户身份的责任。但是，SQL Server 在应用程序访问数据库时仍需对其进行验证，因此应用程序必须提供密码，因为没有其它方法可以验证应用程序。如果不需要对数据库进行特殊访问，则不需要授予用户和 Windows NT 4.0 或 Windows 2000 组任何权限，因为所有权限都可以由它们用来访问数据库的应用程序指派。在这种环境下，假设对应用程序的访问是安全的，则在系统范围内统一使用指派给应用程序角色的密码是可能的。有几个选项可用于管理应用程序角色密码而无须将其硬编码到应用程序中。例如，可以使用存储在注册表（或 SQL Server 数据库）中的加密键，只有应用程序有加密键的解密代码。应用程序读取键，对其进行解密，并使用其值设置应用程序角色。如果使用多协议 Net-Library，则含有密码的网络数据包也可以被加密。另外，当角色被激活时，可以在发送到 SQL Server 实例前将密码加密。如果应用程序用户使用 Windows 身份验证模式连接到 SQL Server 实例，则在使用应用程序时，可以使用应用程序角色设置 Windows NT 4.0 或 Windows 2000 用户在数据库中拥有的权限。这种方法使得当用户使用应用程序时，对用户帐户的 Windows NT 4.0 或 Windows 2000 审核及对用户权限的控制容易维护。如果使用 SQL Server 身份验证，并且不要求审核用户在数据库中的访问，则应用程序可以更容易地使用预定义的 SQL Server 登录连接到 SQL Server 实例。例如，订单输入应用程序验证运行该应用程序的用户，然后用相同的 OrderEntry 登录连接到 SQL Server 实例。所有连接都使用同一登录，相关权限授予该登录。一块学习！我是丛帮助中摘的！不好意思！