There is no predefined maximum size of a stored procedure.
A user-defined stored procedure can be created only in the current database. Temporary procedures are an exception to this because they are always created in tempdb. If a schema name is not specified, the default schema of the user that is creating the procedure is used. For more information about schemas, see User-Schema Separation.
The CREATE PROCEDURE statement cannot be combined with other Transact-SQL statements in a single batch.
By default, parameters are nullable. If a NULL parameter value is passed and that parameter is used in a CREATE TABLE or ALTER TABLE statement in which the referenced column does not allow null values, the Database Engine generates an error. To prevent passing NULL to a column that does not allow for null values, add programming logic to the procedure or use a default value for the column by using the DEFAULT keyword of CREATE TABLE or ALTER TABLE.
We recommend that you explicitly specify NULL or NOT NULL for each column in a temporary table. The ANSI_DFLT_ON and ANSI_DFLT_OFF options control the way the Database Engine assigns the NULL or NOT NULL attributes to columns when these attributes are not specified in a CREATE TABLE or ALTER TABLE statement. If a connection executes a stored procedure with different settings for these options than the connection that created the procedure, the columns of the table created for the second connection can have different nullability and exhibit different behavior. If NULL or NOT NULL is explicitly stated for each column, the temporary tables are created by using the same nullability for all connections that execute the stored procedure.
Using SET Options
The Database Engine saves the settings of both SET QUOTED_IDENTIFIER and SET ANSI_NULLS when a Transact-SQL stored procedure is created or modified. These original settings are used when the stored procedure is executed. Therefore, any client session settings for SET QUOTED_IDENTIFIER and SET ANSI_NULLS are ignored when the stored procedure is running. Other SET options, such as SET ARITHABORT, SET ANSI_WARNINGS, or SET ANSI_PADDINGS are not saved when a stored procedure is created or modified. If the logic of the stored procedure depends on a particular setting, include a SET statement at the start of the procedure to guarantee the appropriate setting. When a SET statement is executed from a stored procedure, the setting remains in effect only until the stored procedure has finished running. The setting is then restored to the value the stored procedure had when it was called. This enables individual clients to set the options they want without affecting the logic of the stored procedure.
Note: |
|---|
|
ANSI_WARNINGS is not honored when you pass parameters in a stored procedure, user-defined function, or when you declare and set variables in a batch statement. For example, if a variable is defined as char(3), and then set to a value larger than three characters, the data is truncated to the defined size and the INSERT or UPDATE statement succeeds.
|
Using Parameters with CLR Stored Procedures
The parameters of a CLR stored procedure can be any one of the scalar SQL Server system data types.
For the Database Engine to reference the correct method when it is overloaded in the .NET Framework, the method indicated in <method_specifier> must have the following characteristics:
-
Be declared as a static method.
-
Receive the same number of parameters as the number of parameters of the procedure.
-
Not be a constructor or destructor of its class.
-
Use parameter types that are compatible with the data types of the corresponding parameters of the SQL Server procedure. For information about matching SQL Server data types to the .NET Framework data types, see Mapping CLR Parameter Data.
-
Return either void or a value of type SQLInt32, SQLInt16, System.Int32, or System.Int16.
-
Return its parameters by reference, not by value, when OUTPUT is specified for any specific parameter declaration.
Getting Information About Stored Procedures
To display the definition of a Transact-SQL stored procedure, use the sys.sql_modules catalog view in the database in which the procedure exists.
For example:
USE AdventureWorks;
GO
SELECT definition
FROM sys.sql_modules
JOIN sys.objects ON sys.sql_modules.object_id = sys.objects.object_id AND TYPE = 'P';
Note: |
|---|
|
The text of a stored procedure created with the ENCRYPTION option cannot be viewed by using the sys.sql_modules catalog view.
|
For a report about the objects referenced by a procedure, query the sys.sql_expression_dependencies catalog view or use sys.dm_sql_referenced_entities and sys.dm_sql_referencing_entities.
To display information about CLR stored procedures, use the sys.assembly_modules catalog view in the database in which the procedure exists.
To display information about the parameters that are defined in a stored procedure, use the sys.parameters catalog view in the database in which the procedure exists.
Deferred Name Resolution
You can create stored procedures that reference tables that do not yet exist. At creation time, only syntax checking is performed. The stored procedure is not compiled until it is executed for the first time. Only during compilation are all objects referenced in the stored procedure resolved. Therefore, a syntactically correct stored procedure that references tables that do not exist can be created successfully; however, the stored procedure will fail at run time if the referenced tables do not exist. For more information, see Deferred Name Resolution and Compilation.
Executing Stored Procedures
When you execute a user-defined stored procedure, either in a batch or inside a module such as a user-defined stored procedure or function, we strongly recommend qualifying the stored procedure name with a schema name.
Parameter values can be supplied if a stored procedure is written to accept them. The supplied value must be a constant or a variable. You cannot specify a function name as a parameter value. Variables can be user-defined or system variables, such as @@SPID.
For more information, see Executing Stored Procedures (Database Engine).
When a procedure is executed for the first time, it is compiled to determine an optimal access plan to retrieve the data. Subsequent executions of the stored procedure may reuse the plan already generated if it still remains in the plan cache of the Database Engine. For more information, see Execution Plan Caching and Reuse.
Parameters That Use the cursor Data Type
Transact-SQL stored procedures can use the cursor data type only for OUTPUT parameters. If the cursor data type is specified for a parameter, both the VARYING and OUTPUT parameters are required. If the VARYING keyword is specified for a parameter, the data type must be cursor and the OUTPUT keyword must be specified. For more information, see Using the cursor Data Type in an OUTPUT Parameter.
Temporary Stored Procedures
The Database Engine supports two types of temporary procedures: local and global. A local temporary procedure is visible only to the connection that created it. A global temporary procedure is available to all connections. Local temporary procedures are automatically dropped at the end of the current session. Global temporary procedures are dropped at the end of the last session using the procedure. For more information, see Creating Stored Procedures (Database Engine).
Automatically Executing Stored Procedures
One or more stored procedures can execute automatically when SQL Server starts. The stored procedures must be created by the system administrator in the master database and executed under the sysadmin fixed server role as a background process. The procedures cannot have any input or output parameters. For more information, see Automatic Execution of Stored Procedures.
Stored Procedure Nesting
Stored procedures can be nested. This means one stored procedure can call another. The nesting level is incremented when the called procedure starts running, and decremented when the called procedure finishes running. Stored procedures can be nested up to 32 levels. For more information, see Nesting Stored Procedures.
To estimate the size of a compiled stored procedure, use the following Performance Monitor Counters.
|
Performance Monitor object name
|
Performance Monitor Counter name
|
|---|
|
SQLServer: Plan Cache Object
|
Cache Hit Ratio
|
|
|
Cache Pages
|
|
|
Cache Object Counts*
|
* These counters are available for various categories of cache objects including ad hoc sql, prepared sql, procedures, triggers, and so on.
For more information, see SQL Server, Plan Cache Object.
<sql_statement> Limitations
Any SET statement can be specified inside a stored procedure, except SET SHOWPLAN_TEXT and SET SHOWPLAN_ALL. These must be the only statements in the batch. The SET option chosen remains in effect during the execution of the stored procedure and then reverts to its former setting.
Inside a stored procedure, object names used in all Data Definition Language (DDL) statements such as CREATE, ALTER, or DROP statements, DBCC statements, EXECUTE and dynamic SQL statements must be qualified with the name of the object schema if users other than the stored procedure owner are to use the stored procedure. For more information, see Designing Stored Procedures (Database Engine).