SQL Module metadata

May 11, 2010 21:38 by Matt Whitfield

So what are SQL modules? Simply put, SQL modules are objects in the database that are programmed in SQL. This isn't entirely accurate, as there are a few SQL programmable object types that don't fall under the 'sql module' banner. These are:

  • Computed columns
  • Check constraints
  • Default constraints

So, effectively, that leaves us with stored procedures, replication filter procedures, the three types of functions (scalar, in-line table-valued and multi-statement table-valued) as well as both DML and DDL triggers. Also, the legacy 'standalone rule' and 'standalone default' object definitions count as SQL modules. However, the less said about them the better, frankly! The meta-data for these objects is stored in the system view [sys].[sql_modules] - so let's look at what we're offered:

object_idThis is the ID of the object to which this definition applies. Unlike previous versions of SQL Server, there will be only one entry per object ID, since the entire definition can be stored in a varchar(MAX) field.
definitionThis is the actual text that represents the module at the time that it was created. Note that this may not be the same as the text needed to re-create an object, because name changes effected with sp_rename are not reflected in this definition. Client side code, whether in SSMS, our very own sql editor or any other editor is responsible for replacing the old object name with the new. Some (SSMS included) fail to re-create the object correctly under various circumstances (for example, if comments are placed between the schema and object names), so tread with care if using this definition to recreate objects. This column will show as NULL if the was created using WITH ENCRYPTION keyword.
uses_ansi_nullsThis is 1 if SET ANSI_NULLS was ON when the module was created.
uses_quoted_identifierThis is 1 if SET QUOTED_IDENTIFIER was ON when the module was created.
is_schema_boundThis is 1 if the module is schema bound - i.e. was defined with the WITH SCHEMABINDING keyword. Note that this is only relevant to views and functions - procedures and triggers cannot be schema bound.
uses_database_collationThis is 1 if there is a dependency between the collation of the database and the sql module, where the sql module is also schema-bound. This type of dependency means that the database default collation cannot be changed.
is_recompiledThis is 1 if the module was created with the WITH RECOMPILE keyword.
null_on_null_inputThis is 1 if the module will produce a null result on null input. This applies only to functions.
execute_as_principal_idThis is the ID of the database principal specified in the WITH EXECUTE AS clause. If there is no WITH EXECUTE AS clause, then this will be NULL. Explicitly specifying WITH EXECUTE AS CALLER will also result in this column being NULL. Specifying EXECUTE AS OWNER will result in the value being -2. For EXECUTE AS [database_principal_name] or EXECUTE AS SELF, this will be the ID of the relevant database principal in [sys].[database_principals].

So we get nearly enough to create the script for all SQL modules from this one view. The major exception being the correction of object names for sql modules that have had their name changed using sp_rename. Interestingly, if a procedure is altered using ALTER PROCEDURE, then the definition in [sys].[sql_modules] will still contain the CREATE keyword.

About system stored procedures

System stored procedures are not magic, they are just SQL modules. Their defintion can be found in [sys].[all_sql_modules], in exactly the same format as for [sys].[sql_modules]. Ok, so they are slightly magic - they often reference internal objects that you simply don't have access to as a normal SQL user. But, looking at the source of system stored procedures can be a great way to learn more about the internals of SQL server, as well as giving you the basis for creating your own customised versions.

Next time we'll look at some of the extra meta-data that is available around SQL modules, specifically triggers, stored procedures and replication filter procedures.

Tags: , , , ,


Add comment

(Will show your Gravatar icon)

  Country flag

  • Comment
  • Preview


SQL Everywhere

Tag cloud


<<  April 2014  >>

View posts in large calendar