Viewing object dependencies in SQL Server

Deleting or changing objects may affect other database objects like views or procedures that depends on them and in certain instances, can “break” the depending object. An example can be that if a View queries a table and the name of that table changes. The View will no longer function.

In SQL Server there are several ways to find object dependencies.

1. The sp_depends system stored procedure

2. SQL Server dynamic management functions including.

   • sys.dm_sql_referencing_entities

   • sys.dm_sql_referenced_entities

3. The View Dependencies feature in SQL Server Management Studio (SSMS).

sp_depends

sp_depends is a system stored procedure that displays information about all object types (e.g. procedures, tables, etc) that depend on the object specified in the input parameter as well as all objects that the specified object depends on.

The sp_depends procedure accepts one parameter, the name of a database object. E.g. EXECUTE sp_depends ‘ObjectName’

Below are examples, which will be used in this article:

-- New database
CREATE DATABASE TestDB;
GO

USE TestDB
GO

CREATE TABLE UserAddress (
	AddresID INT PRIMARY KEY IDENTITY(1, 1)
	,FirstName VARCHAR(100)
	,Lastname VARCHAR(150)
	,Address VARCHAR(250)
	)
GO

-- New procedure
CREATE PROCEDURE sp_GetUserAddress
AS
BEGIN
	SELECT FirstName
		,Lastname
		,Address
	FROM UserAddress
END
GO

CREATE TABLE Address (
	ID INT NOT NULL IDENTITY(1, 1)
	,City VARCHAR(120)
	,PostalCode INT
	,UserAddressID INT FOREIGN KEY REFERENCES UserAddress(AddresID)
	)
GO

-- New View
CREATE VIEW v_Address
AS
SELECT ID
	,City
	,PostalCode
	,UserAddressID
FROM dbo.Address
GO

CREATE PROCEDURE sp_GetUserCity
AS
BEGIN
	SELECT UserAddress.FirstName
		,UserAddress.Lastname
		,Address.City
	FROM UserAddress
	INNER JOIN Address ON UserAddress.AddresID = Address.UserAddressID
END
GO

-- New Trigger
CREATE TRIGGER trgAfterInsert ON [dbo].[UserAddress]
FOR INSERT
AS
PRINT 'Data entered successfully'
GO

Let’s run these scripts above to create the test objects then execute the following SQL.

EXECUTE sp_depends 'UserAddress'

The following result will be:

• name – name of dependent object

• type – type of dependent object (e.g. table)

If a stored procedure is specified as an argument value in sp_depends, then a name of the table and the column names on which the procedure depends will be shown.

Let’s see how this looks with sp_GetUserAddress

EXECUTE sp_depends 'sp_GetUserAddress'

The following result will be:

• name – name of dependent object

• type – type of dependet object (e.g. table)

• updated – whether the object is updated or not

• selected – object is used in the SELECT statement

• column – column on which the dependency exists

sp_depends does not display triggers.

To illustrate this execute the following code in the query window:

CREATE TRIGGER trgAfterInsert ON [dbo].[UserAddress]
FOR INSERT
AS
PRINT 'Data entered successfully'
GO

Now execute the sp_depends over the UserAddress table, the trgAfterInsert will not appear in the Results table:

sp_dependes in some case does not report dependencies correctly. Let’s look at the situation when an object (e.g. UserAddress) on which other object depends (e.g. sp_GetUserAddress) is deleted and recreated. When sp_dependes is executed using EXECUTE sp_depends ‘sp_GetUserAddress’ or EXECUTE sp_depends ‘UserAddress’ the following message will appear:

“Object does not reference any object, and no objects reference it.”

Sadly, sp_dependes is on the path to deprecation and will be removed from future versions of the SQL Server. But you can use sys.dm_sql_referencing_entities and sys.dm_sql_referenced_entities instead.

sys.dm_sql_referencing_entities

This function returns all objects from the current database which depend on the object that is specified as an argument.

Type the following in the query window:

SELECT referencing_schema_name
	,referencing_entity_name
FROM sys.dm_sql_referencing_entities('dbo.UserAddress', 'Object')

The result will be:

referencing_schema_name – schema of the referencing entity

referencing_entity_name – name of the referencing object

More information about result sets can be found on this link.

sys.dm_sql_referenced_entities

This system function returns all objects from the current database on which specified object depends on.

Enter the following code in the query window:

SELECT referenced_entity_name
	,referenced_minor_name
FROM sys.dm_sql_referenced_entities('dbo.sp_GetUserAddress', 'Object')

The following result will be shown:

referenced_entity_name – Name of the referenced object

referenced_minor_name – Name of the column of the referenced entity

For detailed information about result sets, please visit page on this link.

Referencing vs referenced

The objects that are appears inside the SQL expression are called the referenced entity and the objects which contain expressions are called referencing entity:

When using these two function the schema name (e.g. dbo) must be specified as part of the object name:

SELECT referencing_schema_name
	,referencing_entity_name
FROM sys.dm_sql_referencing_entities('dbo.UserAddress', 'Object')

Otherwise no results will be displayed. Run the query without shema nema (dbo):

SELECT referencing_schema_name
	,referencing_entity_name
FROM sys.dm_sql_referencing_entities('UserAddress', 'Object')

The result will be empty set:

An empty result set will be shown under these situations:

• When is an invalid parameter passed (e.g. ‘dbo.UserAddress’,’NN’ instead dbo.UserAddress’,’Object’)

• When a system object is specified as argument (e.g. sys.all_columns)

• When the specified object does not reference any objects

• The specified object does not exist in the current database

The message 2020

Typically the message 2020 occurs when a referencing object e.g. procedure, calls a referenced object e.g. table or a column from the table that does not exist. For example, if in the Address table change name of the column City to name Town and execute the SELECT * FROM sys.dm_sql_referenced_entities (‘[dbo].[v_Address]’,’Object’) query, the message 2020 will appear.

Execute the following code:

EXEC sys.sp_rename 'dbo.Address.City'
	,'Town'
	,'COLUMN'

SELECT *
FROM sys.dm_sql_referenced_entities('dbo.v_Address', 'OBJECT')

The following message will appear:

Msg 207, Level 16, State 1, Procedure v_Address, Line 6
Invalid column name ‘City’.
Msg 2020, Level 16, State 1, Line 3
The dependencies reported for entity “dbo.v_Address” might not include references to all columns. This is either because the entity references an object that does not exist or because of an error in one or more statements in the entity. Before rerunning the query, ensure that there are no errors in the entity and that all objects referenced by the entity exist.

Troubleshooting

In order to prevent dropping or modifying objects, which depends on another object, the v_Address view should be altered and added the WITH SCHEMABINDING option:

ALTER VIEW v_Address
	WITH SCHEMABINDING
AS
SELECT ID
	,City
	,PostalCode
	,UserAddressID
FROM dbo.Address

Now, when changing the name of the column in the Address table, the following message will appear, which proactively provides information that the object, the table “City” in this example, is a part of another object.

Code:

EXEC sys.sp_rename 'dbo.Address.City'
	,'Town'
	,'COLUMN'

Message:

Msg 15336, Level 16, State 1, Procedure sp_rename, Line 501
Object ‘dbo.Address.City’ cannot be renamed because the object participates in enforced dependencies.

Schema-bound vs Non-schema-bound

There are two types of dependencies: Schema-bound and Non-schema-bound dependencies.

A Schema-bound dependency (SCHEMABINDING) prevents referenced objects from being altered or dropped as long as the referencing object exists

A Non-schema-bound dependency: does not prevent the referenced object from being altered or dropped.

For sys.dm_sql_referenced_entities and sys.dm_sql_referencing_entities dependency information will not be displayed for temporary tables, temporary stored procedures or system objects.

Below is an example of a temporary procedure:

CREATE PROCEDURE #sp_tempData
AS
BEGIN
	SELECT AddresID
		,FirstName
		,Lastname
		,Address
	FROM UserAddress
END

Now, when executing sys.dm_sql_referencing_entities for the table UserAddress the information about the #sp_tempData procedure that depends on the UserAddress will not be shown in the list.

Code:

SELECT referencing_schema_name
	,referencing_entity_name
FROM sys.dm_sql_referencing_entities('dbo.UserAddress', 'Object')

Result:

Viewing Dependencies

Another way to view dependencies between objects is by using the View Dependencies option from SSMS. From the Object Explorer pane, right click on the object and from the context menu, select the View Dependencies option:

This will open the Object Dependencies window. By default, the Object that depend on radio button is selected. This radio button will list in the Dependencies section all objects that depends on the selected object (e.g. Address):

If selected the Object on which radio button, will display in the Dependencies section all objects on which selected object (e.g. Address) depends:

The Selected object section consists of three fields:

• Name – name of the selected object from the Dependencies list

• Type – type of the selected object (e.g.table)

• Dependency type – dependency between two objects (Schema-bound, Non-schema-bound).

Under the Type field the Unresolved Entity type for the object can be appear. This happens when the objects refer to an object that don’t exist in the database. This is equivalent to the Msg 2020 message that appears when using sys.dm_sql_referencing_entities or sys.dm_sql_referenced_entities functions:

3^rd party dependency viewer

ApexSQL Search is add-in, which integrates into SSMS and Visual Studio for SQL object and data text search, extended property management, safe object rename, and relationship visualization.

The add-in can be downloaded from this link.

To see object dependencies, right-click on an object (e.g. stored procedure) from the Object Explorer, and choose the View dependencies option from the ApexSQL Search drop-down menu:

Or select object in the Object Explorer, from the ApexSQL main menu, choose ApexSQL Search menu and from the list select the View dependencies option:

After clicking the Dependency viewer window will appear with the Dependencies pane, which shows all objects that depends on the selected object (e.g. UserAddress), by default this pane appears in lower right side of the Dependency viewer window:

Dependency viewer provides graphical view of all dependencies between objects in the middle of the Dependency viewer window:

Visual dependencies

The Dependency viewer offers various options for filtering, appearance and manipulating objects.

In the Object filter pane, the object types (e.g. view) that will be displayed in the dependency graph can be specified:

In the Object browser pane, specific objects can be selected that will be shown or omitted from the dependency graph:

The Dependencies pane, the complete dependency chain for the selected object in the dependency graph (e.g. Address) can be shown. Children indicate the object that depend on the selected object (aka referencing) and Parents shows the objects from which selected object depends on (aka referenced):

The Layout option under the Display ribbon offers different options for visual organization and display:

For example, the Hierarchical option will organize objects based on the “generation” e.g. parents, children, decendents, so the parent (aka Referencing) will be at the top (UserAddress) and object descendants (aka Referenced) will be under them (sp_GetUserCity). Object of the same generation will be in the same horizontal level:

Using this option, it can easily be determined how many objects depend on a specific object and a determination can be made as to whether it is safe to delete it without breaking relationships

The labels that appears in the dependency graph above (e.g. Select, Trigger, etc.) describe the type of relationship e.g. Select, DRI

For example, there is “Select” label on the relationship between the UserAddress table and sp_GetUserAddress procedure. This is because sp_GetUserAddress contains a SELECT statement referencing the UserAddress table.

On the relationship between two other tables we see the “DRI” label. Declarative Referential Integrity exists between SQL tables only and indicate, in this case, that in the object (FOREIGN KEY – UserAddressID) exists in the Address table that references to the object from the UserAddress table (PRIMARY KEY – AddressID):

The Type option allows choosing which type of relationship will be included in the dependency graph e.g. Children only:

For example, the Parents and descendants option will show all dependencies for the selected object (UserAddress). This option will show the complete dependency chain, including parents, children, and descendants:

More information about the Layout and Type options can be found on this link.

See also:

• sys.dm_sql_referencing_entities (Transact-SQL)
• sys.dm_sql_referenced_entities (Transact-SQL)
• sp_depends (Transact-SQL)