sp_bindexeclass

Associates an execution class with a client application, login, stored procedure, or default execution class.

Syntax

sp_bindexeclass "object_name", "object_type", "scope", "classname"

Parameters

object_name – is the name of the client application, login, or stored procedure to be associated with the execution class, classname. If object_type is df, it should be null.
object_type – identifies the type of object_name. Use:
- ap for application
- df for user-defined default execution class
- lg for login
- pr for stored procedure
- sv for a service task (valid only in threaded mode)
scope – is the name of a client application or login, or it can be NULL for ap, df, lg, or sv objects. For objects, scope is the name of the stored procedure owner (user name). When the object with object_name interacts with the application or login, classname attributes apply for the scope you set.
classname – specifies the type of class to associate with object_name. Values are:
- EC1, EC2, or EC3
- The name of a user-defined execution class
- ANYENGINE

Examples

Example 1 – This statement specifies that Transact-SQL applications execute with EC3 attributes for any login or application process (because the value of scope is NULL) that invokes isql, unless the login or application is bound to a higher execution class:
```
sp_bindexeclass 'isql', 'ap', NULL, 'EC3'
```
Example 2 – This statement specifies that when a login with the system administrator role executes Transact-SQL applications, the login process executes with EC1 attributes. If you have already executed the statement in the first example, then any other login or client application that invokes isql executes with EC3 attributes:
```
sp_bindexeclass 'sa', 'lg', 'isql', 'EC1'
```
Example 3 – This statement assigns EC3 attributes to the stored procedure named my_proc owned by user kundu:
```
sp_bindexeclass 'my_proc', 'PR', 'kundu', 'EC3'
```
Example 4 – This statement assigns CLASS1 attributes to all tasks that are running with default execution attributes:
```
sp_bindexeclass NULL, 'DF', NULL, 'CLASS1'
```
Example 5 – Binds the license heartbeat operation to the core execution task:
```
sp_bindexeclass "License Heartbeat", sv, NULL, core
```

Usage

There are additional considerations when using sp_bindexeclass:

When binding an execution class to a default execution class, all tasks running with default execution attributes run with attributes of the new class.
You can bind service tasks to existing execution classes created to manage user tasks. That is, service tasks and user tasks can coexist in the same execution class.
The monServiceTask monitoring table includes all services tasks, including their name and current binding.
sp_bindexeclass associates an execution class with a client application, login, or stored procedure. It can also associate an execution class to the default execution class. Use sp_addexeclass to create execution classes.
When scope is NULL, object_name has no scope. classname’s execution attributes apply to all of its interactions. For example, if object_name is an application name, the attributes apply to any login process that invokes the application. If object_name is a login name, the attributes apply to a particular login process for any application invoked by the login process.
When binding a stored procedure to an execution class, you must use the name of the stored procedure owner (user name) for the scope parameter. This narrows the identity of a stored procedure when there are multiple invocations of it in the same database.
Due to precedence and scoping rules, the execution class being bound may or may not have been in effect for the object called object_name. The object automatically binds itself to another execution class, depending on other binding specifications, precedence, and scoping rules. If no other binding is applicable, the object binds to the default execution class. If you do not specify a user-defined default execution class, then the object binds to the system-defined execution class EC2.
You can use sp_bindexeclass to bind a RepAgent thread to an execution class using rep agent as the application without generating an error. However, because of restrictions in the SAP ASE server, the priority attribute is set to medium, and the binding has no effect.
Binding fails when you attempt to bind an active process to an engine group with no online engines.
The SAP ASE server creates a row in the sysattributes table containing the object ID and user ID in the row that stores data for the binding.
A stored procedure must exist before it can be bound.
Stored procedure bindings must be done in the database in which the stored procedure resides. Therefore, when binding system procedures, execute sp_bindexeclass from within the sybsystemprocs database.
Only the “priority attribute” of the execution class is used when you bind the class to a stored procedure.
The name of the owner of a stored procedure must be supplied as the scope parameter when you are binding a stored procedure to an execution class. This helps to uniquely identify a stored procedure when multiple stored procedures with the same name (but different owners) exist in the database.

Permissions

The permission checks for sp_bindexeclass differ based on your granular permissions settings.

Setting	Description
Enabled	With granular permissions enabled, you must be a user with `manage any execution class` privilege. For ECO, you must be a user with `manage any execution class` and sybase_ts_role.
Disabled	With granular permissions disabled, you must be a user with sa_role. For ECO, you must be a user with sa_role and sybase_ts_role.

Auditing

Values in event and extrainfo columns from the sysaudits table are:

Information	Values
Event	38
Audit option	exec_procedure
Command or access audited	Execution of a procedure
Information in `extrainfo`	Roles – Current active roles Keywords or options – NULL Previous value – NULL Current value – NULL Other information – All input parameters Proxy information – Original login name, if set proxy in effect