Database Files & Objects – Part 4

Today, I will be continuing my talk on database objects that can be viewed through the system catalog views or system stored procedures. A Microsoft SQL Server database is composed of many different objects.

We will be investigating how to retrieve information on these objects in the [MATH] sample database. Please see my first article that creates this database. I will be focusing on functions, stored procedures, triggers and views in this article.

Let’s use the USE statement to select the sample database.

VIEWS – MSDN QUOTE:
“A view can be thought of as either a virtual table or a stored query. The data accessible through a view is not stored in the database as a distinct object. What is stored in the database is a SELECT statement. The result set of the SELECT statement forms the virtual table returned by the view. A user can use this virtual table by referencing the view name in Transact-SQL statements the same way a table is referenced.”

If we want to get a simple list of all the views in a database, one can query the sys.tables catalog view.

STORED PROCEDURES – MSDN QUOTE:
“A stored procedure in SQL Server is a group of one or more Transact-SQL statements or a reference to a Microsoft .NET Framework Common Runtime Language (CLR) method. Procedures resemble constructs in other programming languages because they can: accept input parameters and return multiple values in the form of output parameters to the calling program; contain programming statements that perform operations in the database include calling other procedures; and return a status value to a calling program to indicate success or failure.”

If we want to get a simple list of all the stored procedures in a database, one can query the sys.procedures catalog view.

DML TRIGGERS – MSDN QUOTE:
“DML triggers are a special type of stored procedure that automatically takes effect when a data manipulation language event takes place that affects the table or view defined in the trigger. DML events include INSERT, UPDATE, or DELETE statements. DML triggers can be used to enforce business rules and data integrity, query other tables, and include complex Transact-SQL statements. The trigger and the statement that fires it are treated as a single transaction, which can be rolled back from within the trigger.

If we want to get a simple list of all the DML triggers in a database, one can query the sys.triggers catalog view.

DDL TRIGGERS – MSDN QUOTE:
“You can use DDL triggers to audit database or server operations that create, modify, or delete database objects or ensure that DDL statements enforce your business rules before they are run. DDL triggers fire in response to a variety of Data Definition Language (DDL) events. These events primarily correspond to Transact-SQL statements that start with the keywords CREATE, ALTER, DROP, GRANT, DENY, REVOKE or UPDATE STATISTICS. Certain system stored procedures that perform DDL-like operations can also fire DDL triggers.”

If we want to get a simple list of all the DDL triggers in a database, one can query the sys.server_triggers catalog view. Since we have no objects of this type, the result set is empty.

FUNCTIONS – MSDN QUOTE:
“A user-defined function is a Transact-SQL or common language runtime (CLR) routine that accepts parameters, performs an action, such as a complex calculation, and returns the result of that action as a value. The return value can either be a scalar (single) value or a table. Use this statement to create a reusable routine that can be used in these ways:

In Transact-SQL statements such as SELECT
In applications calling the function
In the definition of another user-defined function
To parameterize a view or improve the functionality of an indexed view
To define a column in a table
To define a CHECK constraint on a column
To replace a stored procedure”

If we want to get a simple list of all functions in a database, we have to query the catch all sys.objects catalog view. There is no sub-set view like the prior examples.

There is an older system stored procedure that we can used to list basic information on stored procedures and functions. By suppling the object name as a parameter, the sp_stored_procedures will return some very basic information.

There are times as a SQL developer in which you want to know the parameters that are passed to a given stored procedure or function. We can query the sys.parameters catalog view and the filter by all user objects from the sys.objects tables.

Another way to do this same task is to execute the sp_sproc_columns stored procedure with the correct parameter. If we use object owner, we can get both procedures and functions. If we use object name, we will get just one listing.

There are many times that we want to see the code behind these objects. We can query the sys.sql_modules catalog view to get the information and filter by all object type in views, store procedures, triggers or views.

Another way to do this same task is to execute the sp_helptext stored procedure with the correct parameter. If we use object name, we will get just one listing.

large screen shot #1

Last but not least, we can query the sys.objects catalog view to return all user defined objects.

To recap this discussion, system stored procedures can be used grab information about database views, stored procedures, triggers and functions. Use system catalog views instead to get detailed information on both. In the future, I am sure I will be writing TSQL scripts using these commands to do maintenance tasks where third party vendors come up short.

Next time, I will be talking about using system stored procedures and catalog views to look at the following database objects used in file partitioning for large data sets.