There are a couple of extra views which give us some more information about SQL Modules. They relate to specific types of SQL Modules, namely procedures and triggers.
Let's look at [sys].[procedures] first, which gives us some more information about procedures, over and above the information in [sys].[objects]:
is_auto_executed | This is 1 if the procedure is marked for auto-execution at server startup. Note that only procedures in the master database can receive this flag. To mark a procedure for startup execution, we use sp_procoption. For example, to set a procedure called sp_my_startup_procedure to run at startup, we would use the following:exec sp_procoption N'sp_my_startup_procedure', 'startup', 'on'. |
|---|---|
is_execution_replicated | This is 1 if the procedure's execution is replicated. This is achieved by using the proc exec value for the @type parameter of sp_addarticle. |
is_repl_serializable_only | This is 1 if the procedure's execution is replicated, but only when the transaction is serializable. This is achieved by using the serializable proc exec value for the @type parameter of sp_addarticle. |
skips_repl_constraints | This is 1 if the procedure skips contraints marked NOT FOR REPLICATION, usually true only on subscribers. |
So, not really much extra information about procedures. Let's look at [sys].[triggers] which gives us information about triggers, and does not inherit columns from [sys].[objects]:
name | This is the name of the trigger. |
|---|---|
object_id | This is the object ID of the trigger. Both DML and DDL triggers are assigned object IDs, even though DDL triggers are not visible in [sys].[objects]. |
parent_class | This is the parent class of the trigger - specifying whether the trigger is a database parented trigger (for DDL triggers) or an object parented trigger (for DML triggers). It will be 0 for DDL triggers and 1 for DML triggers. |
parent_class_desc | This is the description that relates to the value in the parent_class column. The current values are 'DATABASE' or 'OBJECT_OR_COLUMN'. |
parent_id | This is the ID of the parent object (table or view) for normal DML triggers. For DDL triggers, it will always be 0. |
type | This is the tye code of the trigger, the same as it would be in [sys].[objects]. The trigger type codes are 'TA' for an assembly trigger, or 'TR' for a SQL trigger. |
type_desc | This is the description that relates to the value in the type column. Currently the values are either 'CLR_TRIGGER' or 'SQL_TRIGGER'. |
create_date | This is the date on which the trigger was created. |
modify_date | This is the date on which the trigger was last modified by using an ALTER statement. |
is_ms_shipped | This is 1 if the trigger was created by an internal process, or if the trigger was created as part of the SQL Server installation. |
is_disabled | This is 1 if the trigger has been disabled by using a DISABLE TRIGGER statement. It can be re-enabled by using an ENABLE TRIGGER statement. |
is_not_for_replication | This is 1 if the trigger was created with the NOT FOR REPLICATION option, meaning that it will not fire on subscribers. |
is_instead_of_trigger | This is 1 if the trigger is an INSTEAD OF trigger. These can be useful for creating complex views that can be updated, inserted into or deleted from using normal DML. |
There seems to be quite a lot of information about triggers, but, in effect we're not told that much. We simply find out if the trigger is marked NOT FOR REPLICATION, whether it is enabled and whether it is an INSTEAD OF or AFTER trigger.
One thing that we still don't know about triggers is what events they fire on. For example - does a particular DML trigger fire on an INSERT, an UPDATE, a DELETE or a combination of the three? For the answer, we have to look to another table, [sys].[trigger_events]:
object_id | This is the object_id of the trigger for which the event is defined. You may find multiple rows for a single object_id for triggers that fire on more than one event. |
|---|---|
type | This is the type number of the event that causes the trigger to fire. Triggers that fire on multiple events have multiple rows, with each row specifying a different type value. |
type_desc | This is the description that relates to the value in the type column. |
event_group_type | This is the event group identifier that tells us which event group the trigger was created on. If the trigger was not created on an event group, then this is null. |
event_group_type_desc | This is the description that relates to the value in the event_group_type_desc column. |
is_first | This is 1 if the trigger is marked as the first trigger to fire for the specified event, using the sp_settriggerorder procedure. |
is_last | This is 1 if the trigger is marked as the last trigger to fire for the specified event, using the sp_settriggerorder procedure. |
We now have all the information we need about triggers. A note, though, about the is_first and is_last columns - a lot of people mistakenly believe that you can actually specify the order in which multiple triggers fire. You can't. You can just specify that a trigger must execute first for a particular event, or that a trigger must execute last for a particular event, and not the explicit order of any other triggers in between. However, if you run across this problem, then you probably have bigger issues, as having more than 3 triggers on the same event type for the same parent object would not be a brilliant idea, performance-wise.
Next time we'll look at some of the metadata that surrounds the CLR objects, as well as the assemblies that contain them.