SQL SERVER – Find Stored Procedure Related to Table in Database – Search in All Stored Procedure

Following code will help to find all the Stored Procedures (SP) which are related to one or more specific tables. sp_help and sp_depends does not always return accurate results. Each option below returns every stored procedure related to table names you put in the LIKE filter.

----Option 1
SELECT DISTINCT so.name
FROM syscomments sc
INNER JOIN sysobjects so ON sc.id=so.id
WHERE sc.TEXT LIKE '%tablename%'
----Option 2
SELECT DISTINCT o.name, o.xtype
FROM syscomments c
INNER JOIN sysobjects o ON c.id=o.id
WHERE c.TEXT LIKE '%tablename%'

The version I would write today

syscomments and sysobjects are compatibility views. They still work, and they will for a long while yet, but Microsoft replaced them with the sys catalog views many versions ago. Here is the same search written the modern way.

SELECT s.name AS SchemaName,
       o.name AS ObjectName,
       o.type_desc AS ObjectType
FROM sys.sql_modules AS m
INNER JOIN sys.objects AS o ON m.object_id = o.object_id
INNER JOIN sys.schemas AS s ON o.schema_id = s.schema_id
WHERE m.definition LIKE '%YourTableName%'
ORDER BY o.type_desc, s.name, o.name;

This finds procedures, views, functions and triggers all at once, and type_desc tells you which is which. Drop the WHERE clause on type and you have a search across everything that holds SQL in your database.

The bug in the old approach that nobody mentions

This one caught me years ago and it is worth knowing. syscomments does not store a long procedure as one piece of text. It chops it into chunks of four thousand characters and stores them as separate rows.

So if your table name happens to land across the join between two chunks, the LIKE never matches and the procedure simply does not appear in your results. You get a clean list with nothing obviously wrong, and one procedure quietly missing. On a long procedure that is not a rare accident, it is just luck.

sys.sql_modules stores the definition in one piece, so the problem goes away. That, more than tidiness, is why I moved over.

The proper answer: ask SQL Server what depends on what

Searching text is a blunt instrument. SQL Server actually tracks dependencies, and since SQL Server 2008 there is a reliable view for it.

SELECT OBJECT_SCHEMA_NAME(d.referencing_id) AS SchemaName,
       OBJECT_NAME(d.referencing_id) AS ReferencingObject,
       o.type_desc AS ObjectType
FROM sys.sql_expression_dependencies AS d
INNER JOIN sys.objects AS o ON d.referencing_id = o.object_id
WHERE d.referenced_entity_name = 'YourTableName'
ORDER BY o.type_desc, ReferencingObject;

This is what replaced sp_depends, and it is the one to reach for when the question is “what will break if I change this table”. It understands that the name is a table rather than just a run of letters, so none of the false matches below apply to it.

There is a simpler wrapper around the same idea if you prefer.

SELECT referencing_schema_name, referencing_entity_name, referencing_class_desc
FROM sys.dm_sql_referencing_entities('dbo.YourTableName', 'OBJECT');

Why a plain search gives you answers that are not true

Searching for ‘%Orders%’ with LIKE will happily return:

Procedures that mention Orders only in a comment. Procedures that use a completely different table called OrderDetails or WorkOrders, because your text appears inside the longer name. Procedures that mention it in a string, in a print statement, or in code that was commented out five years ago and never removed.

None of those actually depend on your table, and if you are about to rename a column, that difference matters. Use the dependency view for the real answer, and keep the text search for when you genuinely want to find every place a word is written.

Searching every database at once

The queries above look at one database. If you are hunting for a table across a whole server, run it per database rather than writing something clever. A short loop is fine, but honestly, running it three or four times by hand is usually quicker than debugging a script that walks every database and trips over the one that is offline.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.