In addition to specifying the execution attributes for an object, you can define its scope when you use sp_bindexeclass. The scope specifies the entities for which the execution class bindings will be effective. The syntax is:
sp_bindexeclass object_name, object_type,
scope, class_name
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:
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 case, the scope of the EC1 binding to the “sa” login is the isql client application:
sp_bindexeclass sa, LG, isql, EC1
The execution object’s execution attributes apply to all of its interactions if the scope is NULL.
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 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 non-“sa” logins execute with EC3 attributes.
The scope rule states that when a client application, login, 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 this command:
sp_bindexeclass isql, AP, sa, EC1
