Associates an execution class with a client application, login, stored procedure, or default execution class.
sp_bindexeclass "object_name", "object_type", "scope", "classname"
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.
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)
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.
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
This statement specifies that Transact-SQL applications will 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'
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'
This statement assigns EC3 attributes to the stored procedure named my_proc owned by user kundu:
sp_bindexeclass 'my_proc', 'PR', 'kundu', 'EC3'
This statement assigns CLASS1 attributes to all tasks that are running with default execution attributes:
sp_bindexeclass NULL, 'DF', NULL, 'CLASS1'
Binds the license heartbeat operation to the core execution task:
sp_bindexeclass "License Heartbeat", sv, NULL, core
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 Adaptive 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.
Adaptive 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.
The permission checks for sp_bindexeclass differ based on your granular permissions settings.
Granular permissions 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. |
Granular permissions 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. |
Values in event and extrainfo columns from the sysaudits table are:
Event |
Audit option |
Command or access audited |
Information in extrainfo |
|---|---|---|---|
38 |
exec_procedure |
Execution of a procedure |
|
System procedures sp_addexeclass, sp_showexeclass, sp_unbindexeclass
