Associates an execution class with a client application, login, or stored procedure.
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.
identifies the type of object_name. Use ap for application, lg for login, or pr for stored procedure.
is the name of a client application or login, or it can be NULL for ap and lg objects. It is the name of the stored procedure owner (user name) for objects. 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 will execute 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'
sp_bindexeclass associates an execution class with a client application, login, or stored procedure. Create execution classes with sp_addexeclass.
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, EC2.
It is possible to 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.
Only a System Administrator can execute sp_bindexeclass.
System procedures sp_addexeclass, sp_showexeclass, sp_unbindexeclass
