Adaptive Server Reference Manual: Procedures

sp_addobjectdef

The Usage section of the sp_addobjectdef reference page includes this bullet item, which is incomplete:

Use sp_addobjectdef before issuing any create table or create existing table commands.

Replace with:

Use sp_addobjectdef before issuing any create table or create existing table commands. However, if a remote table exists, you need not use sp_addobjectdef before executing create proxy_table.

sp_bindexeclass

The description of this stored procedure reads: "Associates an execution class with a client application, login, or stored procedure."

Update the description, with "Associates an execution class with a client application, login, stored procedure, or default execution class."

Syntax updates

The definitions of the parameters have been updated:

object_name – the description should now read, "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 – the description should now read, "identifies the type of object_name. Use ap for application, lg for login, pr for stored procedure, or df for user-defined default execution class."
scope – the description should now read, "is the name of a client application or login, or it can be null for ap, lg, or df 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."

Example

Add this to the Example section:

This statement assigns 'CLASS1' attributes to all tasks that are running with default execution attributes:

sp_bindexeclass NULL, 'DF', NULL, 'CLASS1'

Usage updates

Add this new bullet item:

When binding an execution class to a default execution class, all tasks running with default execution attributes run with attributes of the new class.

In addition, these two bullet items have been modified, and should now read:

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.
Due to precedence and scoping rules, the execution class being bound may or may not have been in effect for the 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 user-defined default execution class. If a user-defined default execution class is not specified, then the object binds to the system-defined default execution class EC2.

sp_cacheconfig

The Data Cache Memory subsection in the Usage section of the reference page for sp_cacheconfig includes a bullet item that states, in part:

A data cache requires a small percentage of overhead for structures that manage the cache. All cache overhead is taken from the default data cache.

Since you can configure the default data cache size separately from total memory, the cache overhead is taken from free memory, not the default data cache. For this reason, the bullet should read:

A data cache requires a small percentage of overhead for structures that manage the cache. All cache overhead is taken from free memory.

sp_downgrade

The reference page for sp_downgrade should specify that you can execute this stored procedure only in the master database.

sp_dropexeclass

A bullet item in the Usage section reads as follows:

classname must not be bound to any client application, login, or stored procedure. Unbind the execution class first, using sp_unbindexeclass, then drop the execution class, using sp_dropexeclass.

Replace with:

classname must not be bound to any client application, login, stored procedure, or default execution class. Unbind the execution class first, using sp_unbindexeclass, then drop the execution class, using sp_dropexeclass.

sp_lmconfig

There is a correction to the sp_lmconfig stored procedure. The syntax in the book appears as:

sp_lmconfig
	    [ 'edition' [, edition_type ]]
	    [ , 'license type' [ , license_type_name ]]
	    [ , 'smtp host' [ , smtp_host_name ]]
	    [ , 'smtp port' [ , smtp_port_number ]]
	    [ , 'email sender' [ , sender_email_address ]]
	    [ , 'email recipients' [ , email_recipients ]]]
	    [ , 'email severity' [ , email_severity ]]

Replace with:

sp_lmconfig
     [
        [ 'edition' [, edition_type ]]                 |
        [ 'license type' [, license_type_name ]]       |
        [ 'smtp host' [, smtp_host_name ]]             |
        [ 'smtp port' [, smtp_port_number ]]           |
        [ 'email sender' [, sender_email_address ]]    |
        [ 'email recipients' [, email_recipients ]]    |
        [ 'email severity' [, email_severity ]]
     ]

The sp_lmconfig procedure, when executed without parameters, also displays the server name from where the license is checked out. Example #1 in the reference page should display the following, with the addition of the column "Server Name."

1> sp_lmconfig
2> go

 Parameter Name    Config Value
 ----------------- ------------
 edition           EE
 license type      CP
 smtp host         null
 email recipients  null
 email severity    null
 smtp port         null
 email sender      null

 License Name         Version    Quantity Status     Expiry Date         Server Name
 ---------------      ---------- -------- ---------- ------------------- --------------------
 ASE_HA               2010.03314 2        expirable  Apr 1 2010 12:00AM cuprum
 ASE_ASM              null       0        not used   null                null
 ASE_EJB              null       0        not used   null                null
 ASE_EFTS             null       0        not used   null                null
 ASE_DIRS             null       0        not used   null                null
 ASE_XRAY             null       0        not used   null                null
 ASE_ENCRYPTION       null       0        not used   null                null
 ASE_CORE             2010.03314 2        expirable  Apr 1 2010 12:00AM cuprum
 ASE_PARTITIONS       null       0        not used   null                null
 ASE_RLAC             null       0        not used   null                null
 ASE_MESSAGING_TIBJMS null       0        not used   null                null
 ASE_MESSAGING_IBMMQ  null       0        not used   null                null
 ASE_MESSAGING_EASJMS null       0        not used   null                null

 Property Name Property Value
 ------------- --------------
 PE            EE
 LT            CP
 ME            null
 MC            null
 MS            null
 MM            null
 CP            0
 AS            A

(return status = 0)

sp_locklogin

Examples 2 and 4 use all, which sp_locklogin does not recognize . A note in the Usage section correctly states:

Note: A value of NULL for a login means all logins."

Example 2 locks all logins except those with the sa_role. The erroneous syntax is:

sp_locklogin "all", "lock", sa_role

Replace with:

sp_locklogin NULL, "lock", sa_role

Example 4 locks all login accounts that have not authenticated within the past 60 days. The erroneous syntax is:

sp_locklogin 'all', 'lock', NULL, 60

Replace with:

sp_locklogin NULL, 'lock', NULL, 60

sp_reportstats

In the reference page for sp_reportstats, disregard the following bullet, which no longer applies:

sp_reportstats does not report statistics for any process with a system user ID (suid) of 0 or 1. This includes deadlock detection, checkpoint, housekeeper, network, auditing, mirror handlers, and all users with sa_role.

sp_showcontrolinfo

The definitions of the parameters have been updated:

object_name – the description should now read, "is the name of the application, login, stored procedure, or engine group. Do not specify an object_name if you specify ps or DF as the object_type. If you do not specify an object_name (or specify an object_name of null), sp_showcontrolinfo displays information about all object names."
object_type – the description should now read, "is ap for application, lg for login, pr for stored procedure, eg for engine group, ps for process, or df for user-defined default execution class. If you do not specify an object_type or specify an object_type of null, sp_showcontrolinfo displays information about all types."

Usage updates

Add these two bullets:

If object_type is df, sp_showcontrolinfo shows information about the user-defined default execution class any.
If object_type is df, object_name and spid should be null.

sp_unbindexeclass

The description of this stored procedure reads: "Removes the execution class attribute previously associated with an client application, login, or stored procedure for the specified scope."

Update the description with: "Removes the execution class attribute previously associated with a client application, login, stored procedure, or default execution class for the specified scope."

Syntax updates

The definitions of the parameters have been updated:

object_name – the description should now read, "is the name of the application, login, or stored procedure for which to remove the association to the execution class. If object_type is df, object_name should be null."
object_type – the description should now read, "identifies the type of object_name as ap, lg, pr, or df for application, login, stored procedure, or default execution class."
scope – the description should now read, "is the application name or the login name for which the unbinding applies for an application or login. For stored procedures, scope is the user name of the stored procedure owner. scope is null for object type df."

Usage updates

Add this bullet item:

When unbinding from user-defined default execution class, all tasks running with user-defined default execution class attributes run with attributes of the system-defined default execution class EC2.

The following bullet item appears in the Usage section:

"Due to precedence and scoping rules, the execution class being unbound 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 and precedence and scoping rules. If no other binding is applicable, the object binds to the default execution class, EC2."

The text has been modified to read:

"Due to precedence and scoping rules, the execution class being unbound may or may not have been in effect for the object_name. The object automatically binds itself to another execution class, depending on other binding specifications, and precedence and scoping rules. If no other binding is applicable, the object binds to the user-defined default execution class. If there is no user-defined default execution class, the object binds to class EC2."