Scope rule

In addition to specifying the execution attributes for an object, you can define its scope when you use sp_bindexeclass scope. The object’s scope specifies the entities for which the execution class bindings are effective

For example, you can specify that an isql client application run with EC1 attributes, but only when it is executed by an “sa” login. This statement sets the scope of the EC1 binding to the isql client application as the “sa” login (AP indicates an application):

sp_bindexeclass isql, AP, sa, EC1

Conversely, you can specify that the “sa” login run with EC1 attributes, but only when it executes the isql client application. In this example, the scope of the EC1 binding to the “sa” login is the isql client application:

sp_bindexeclass sa, LG, isql, EC1

If the scope is set to NULL, the binding is for all interactions.

When a client application has no scope, the execution attributes bound to it apply to any login that invokes the client application.

When a login has no scope, the attributes apply to the login for any process that the login invokes.

The isql parameter in the following command specifies that Transact-SQL applications execute with EC3 attributes for any login that invokes isql, unless the login is bound to a higher execution class:

sp_bindexeclass isql, AP, NULL, EC3

Combined with the bindings above that grant the “sa” user of isql EC1 execution attributes, and using the precedence rule, an isql request from the “sa” login executes with EC1 attributes. Other processes servicing isql requests from logins that are not “sa” execute with EC3 attributes.

The scope rule states that when a client application, login, service class, or stored procedure is assigned multiple execution class levels, the one with the narrowest scope has precedence. Using the scope rule, you can get the same result if you use:

sp_bindexeclass isql, AP, sa, EC1