If I have two trivial stored procedures, created like so:
create procedure root as
select 1
go
create procedure dependant as
exec root
go
(Where dependant depends on root).
When I check the sys.sql_dependencies table for the second procedure, I see an entry (as i would expect).
If, however, I add the dependant procedure first, I get the following warning.
Cannot add rows to
sys.sql_dependencies for the stored
procedure because it depends on the
missing table ‘root’. The stored
procedure will still be created;
however, it cannot be successfully
executed until the table exists.
And, right enough, exec dependant; fails.
So, when I add in the root procedure, exec dependant; works, however, no dependency is recorded on sys.sql_dependencies.
My questions are twofold:
- What are the consequences of this?
- Everything seems to hang together quite acceptably, so why doesn’t SQL add this record retrospectively?
Help, as always is much appreciated.
The consequences are just that when you come to refactor the database it is more difficult to identify affected objects.
You can refresh all dependencies by writing a script to run
sp_refreshsqlmoduleon all database objects.In SQL Server 2008 such unresolved dependencies are still stored and are accessible through
sys.sql_expression_dependenciesmeaning the dependency information is more reliable.The SQL Server 2008 behaviour is as follows.
After dependant is created but before root exists
Returns
In your example code this is also the results of the query following the creation of
rootas the reference to it is not schema qualified and so is caller dependent. However if the definition of yourdependantprocedure is changed toThen once
dbo.rootis created the following is returned