SQL Server Engine Tips : Catalog Views

Using catalog views in SQL Server 2005

SQL Server Engine Team — Wed, 06 Sep 2006 21:31:00 GMT

Did you know that the catalog views in SQL Server 2005 exposes metadata for various objects in a database and at the server-level? This is the preferred method of accessing metadata. It is a much richer mechanism that doesn't require access to system tables or undocumented columns or status bits. If you want standard and portable access to metadata then you can still use the INFORMATION_SCHEMA views but it is limited to standard specific features, data types and views.

I have posted several topics in the past that shows how to use the information in various catalog views. And the Books Online Documentation has a topic that has answers to several frequently asked questions. It shows you how to use the catalog views to get answers to following questions for example:

How do I find the LOB data types of a specified table?
How do I find the CHECK constraints that depend on a specified CLR user-defined type?

How do I find the dependencies on a specified function?

How do I find all the owners of entities contained in a specified schema?

You can find the topic using the links below:

Books Online in MSDN: http://msdn2.microsoft.com/en-us/library/ms345522.aspx

Books Online Client: ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/ca202580-c37e-4ccd-9275-77ce79481f64.htm

Please check it out and send your feedback using the Books Online feedback mechanism if you want to see additional questions. You can also post such questions here and I will write the queries using the catalog views.

Umachandar

Use of INFORMATION_SCHEMA views to access temp tables.

SQL Server Engine Team — Sat, 08 Oct 2005 05:06:00 GMT

An MVP recently sent us an email asking how to use the INFORMATION_SCHEMA views to access temp tables. This MVP thought the session ID (spid) was needed to construct the suffix. Here was our response:

=========================

Hi,

The algorithm for generating the temp table name suffix changed between Shiloh in Yukon. In any case, it is not based upon the session id.

I suggest you give your temp table unique prefixes and do this:

use tempdb
go

select *
from   INFORMATION_SCHEMA.TABLES
where TABLE_CATALOG = 'tempdb'
and    TABLE_SCHEMA = USER
and    TABLE_NAME like '#DIRECTORY%'
go

Note that TABLE_SCHEMA = USER only works in Shiloh. Reason - because of the user/schema separation feature. In Yukon, the TABLE_SCHEMA is really that ... the table's schema name... which might not be the same as the user name. We have real schemas now. User X can own schemas Y and Z. All schema names occupy the same namespace regardless of owner, however.

Another difference between Shiloh and Yukon is this: You cannot use 3-part names to refer to tempdb from another database context unless you are sa. You must "use" tempdb and stick to a 2-part name, as shown in the example above. This works in Yukon, however, for non-sa users.

In Summary

For Shiloh
- TABLE_SCHEMA = user name
- This won’t work from non-tempdb calling context unless you’re sa/dbo. You get an empty set back.

use otherdb
go

select * from tempdb.INFORMATION_SCHEMA.TABLES
go

The temp table name is formed from login time stamp + nest level.

For Yukon

TABLE_SCHEMA = schema name
This will work from non-tempdb calling context even if you are a least-privileged user. You get the rows back.

use otherdb
go

select * from tempdb.INFORMATION_SCHEMA.TABLES
go

Formed from an internal counter.

If you want to write code that works both on Shiloh and Yukon for non-sa users, then:

a) You must "use tempdb"
b) You must use 2-part name: SELECT * FROM INFORMATION_SCHEMA.TABLES
c) You must assume that for Yukon customers, the schema name == user name. This will be the case for all upgraded databases. This will also hold true as long as your customers avoid user/schema separation features. This will hold true for the old “sp_adduser” API.
d) You can enforce (c) this by using DDL triggers in Yukon and doing ROLLBACKs on CREATE SCHEMA and CREATE USER statements.

Clifford Dibble
Program Manager, SQL Server Engine

Determine primary keys and unique keys for all tables in a database...

SQL Server Engine Team — Fri, 16 Sep 2005 21:27:00 GMT

With SQL Server 2005, there are new ways to obtain richer metadata in a database and more efficiently. We have introduced new catalog views that exposes all the metadata that SQL Server uses and can be created by various DDL statements. The older ANSI SQL style INFORMATION_SCHEMA views are also still available if you want to write portable queries. I already posted a tip about finding dependencies http://blogs.msdn.com/sqltips/archive/2005/07/05/435882.aspx between various objects using the new catalog views. Here are two queries that show you how to retrieve primary/unique key details for all tables in a database:

-- ANSI SQL compatible and works from SQL70 onwards:

select kcu.TABLE_SCHEMA, kcu.TABLE_NAME, kcu.CONSTRAINT_NAME, tc.CONSTRAINT_TYPE, kcu.COLUMN_NAME, kcu.ORDINAL_POSITION
from INFORMATION_SCHEMA.TABLE_CONSTRAINTS as tc
join INFORMATION_SCHEMA.KEY_COLUMN_USAGE as kcu
    on kcu.CONSTRAINT_SCHEMA = tc.CONSTRAINT_SCHEMA
   and kcu.CONSTRAINT_NAME = tc.CONSTRAINT_NAME
   and kcu.TABLE_SCHEMA = tc.TABLE_SCHEMA
   and kcu.TABLE_NAME = tc.TABLE_NAME
where tc.CONSTRAINT_TYPE in ( 'PRIMARY KEY', 'UNIQUE' )
order by kcu.TABLE_SCHEMA, kcu.TABLE_NAME, tc.CONSTRAINT_TYPE, kcu.CONSTRAINT_NAME, kcu.ORDINAL_POSITION;

-- SQL Server 2005 specific:

select s.name as TABLE_SCHEMA, t.name as TABLE_NAME

     , k.name as CONSTRAINT_NAME, k.type_desc as CONSTRAINT_TYPE
     , c.name as COLUMN_NAME, ic.key_ordinal AS ORDINAL_POSITION
from sys.key_constraints as k
join sys.tables as t
    on t.object_id = k.parent_object_id
join sys.schemas as s
    on s.schema_id = t.schema_id
join sys.index_columns as ic
    on ic.object_id = t.object_id
   and ic.index_id = k.unique_index_id
join sys.columns as c
    on c.object_id = t.object_id
   and c.column_id = ic.column_id
order by TABLE_SCHEMA, TABLE_NAME, CONSTRAINT_TYPE, CONSTRAINT_NAME, ORDINAL_POSITION;

Direct dependencies on a column...

SQL Server Engine Team — Wed, 06 Jul 2005 04:39:00 GMT

I came across a question recently about discovering the constraints that are dependent on a column like CHECK constraint, defaults and so on. In trying to solve that problem, I came across few interesting solutions that uses some new relational features and the catalog views available in SQL Server 2005. I will share those here. There is a wealth of information exposed via the catalog views in SQL Server 2005 and be sure to check that out in the Books Online.

Let's now look at the problem. Given the schema objects below, I want to identity all the direct dependencies on the column "t.c".

use tempdb;
go
create table t (
   c char(1) not null
   constraint df_t_c default( '' )
   constraint ck_t_c check( c > '' )
   constraint pk_t_c primary key
   constraint fk_t_c references t (c),
   c1 as c
);

create unique nonclustered index ix_t_c on t( c );
go
create view vt with schemabinding as select c from dbo.t;
go

The direct dependencies in this sample schema include the following: check constraint, default constraint, primary key, foreign key, computed column, index and the view. Before jumping into the solution, there are legitimate cases where you may want to get such dependencies - for reporting or modifying schema elements.

Here is the query to get only the dependent constraints for the column:

with constraint_depends
as
(
select c.TABLE_SCHEMA, c.TABLE_NAME, c.COLUMN_NAME, c.CONSTRAINT_NAME
from INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE as c
union all
select s.name, o.name, c.name, d.name
from sys.default_constraints as d
join sys.objects as o
    on o.object_id = d.parent_object_id
join sys.columns as c
    on c.object_id = o.object_id and c.column_id = d.parent_column_id
join sys.schemas as s
    on s.schema_id = o.schema_id
)
select c.TABLE_SCHEMA, c.TABLE_NAME, c.COLUMN_NAME, c.CONSTRAINT_NAME
from constraint_depends as c
where c.TABLE_NAME = 't' and c.COLUMN_NAME = 'c';
go

TABLE_SCHEMA   TABLE_NAME COLUMN_NAME CONSTRAINT_NAME
dbo            t          c           fk_t_c
dbo            t          c           pk_t_c
dbo            t          c           ck_t_c
dbo            t          c           df_t_c

This query uses the INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE view to get information about all constraints except defaults (since standard doesn't include default as constraint the view doesn't expose that). And the defaults are obtained using the sys.default_constraints catalog view. The information in the query can be used to say drop the constraints before dropping the column from a script.

Now, the next query uses only the new catalog views to obtain all the required information.

with rel_objs (obj_name, type_name, type_desc, parent_object_id, parent_column_id)
as
(
select d.name, d.type, d.type_desc, d.parent_object_id, d.parent_column_id
from sys.default_constraints as d -- defaults
union all
select c.name, c.type, c.type_desc, c.parent_object_id, c.parent_column_id
from sys.check_constraints as c -- check constraints
union all
select k.name, k.type, k.type_desc, k.parent_object_id, kc.column_id
from sys.key_constraints as k -- primary key and unique constraints
join sys.index_columns as kc
    on kc.object_id = k.parent_object_id and kc.index_id = k.unique_index_id
union all
select f.name, f.type, f.type_desc, f.parent_object_id, fc.parent_column_id
from sys.foreign_keys as f -- foreign key constraints
join sys.foreign_key_columns as fc
    on fc.constraint_object_id = f.object_id and fc.parent_object_id = f.parent_object_id
union all
select c.name, 'CC', 'COMPUTED_COLUMN', d.referenced_major_id, d.referenced_minor_id
from sys.sql_dependencies as d -- computed columns
join sys.columns as c
    on c.object_id = d.object_id and c.column_id = d.column_id
where d.object_id = d.referenced_major_id and d.referenced_minor_id > 0 and d.column_id > 0
union all
select o.name, o.type, o.type_desc, d.referenced_major_id, d.referenced_minor_id
from sys.sql_dependencies as d -- views
join sys.objects as o
    on o.object_id = d.object_id
where d.object_id <> d.referenced_major_id and d.referenced_minor_id > 0 and o.type = 'V'
union all
select i.name, 'IX', i.type_desc, i.object_id, ic.column_id
from sys.indexes as i -- indexes
join sys.index_columns as ic
    on ic.index_id = i.index_id and ic.object_id = i.object_id
where i.is_primary_key = 0 and i.is_unique_constraint = 0
),
rel_objs_det (schema_name, table_name, column_name, rel_obj_name, rel_type_name, rel_type_desc)
as (
select s.name, o.name, c.name, r.obj_name, r.type_name, r.type_desc
from rel_objs as r -- names for the table/column to query for:
join sys.objects as o
    on r.parent_object_id = o.object_id
join sys.columns as c
    on c.object_id = o.object_id and c.column_id = r.parent_column_id
join sys.schemas as s
    on s.schema_id = o.schema_id
)
select r.schema_name, r.table_name, r.column_name, r.rel_obj_name, r.rel_type_name, r.rel_type_desc
from rel_objs_det as r
where r.table_name = 't' and r.column_name = 'c'; /* MODIFY or REMOVE where clause if you want run this query for other tables. */
go

schema_name   table_name   column_name   rel_obj_name   rel_type_name   rel_type_desc
dbo           t            c             df_t_c         D               DEFAULT_CONSTRAINT
dbo           t            c             ck_t_c         C               CHECK_CONSTRAINT
dbo           t            c             pk_t_c         PK              PRIMARY_KEY_CONSTRAINT
dbo           t            c             fk_t_c         F               FOREIGN_KEY_CONSTRAINT
dbo           t            c             c1             CC              COMPUTED_COLUMN
dbo           t            c             vt             V               VIEW
dbo           t            c             ix_t_c         IX              NONCLUSTERED

This query highlights the use of several catalog views: default_constraints, check_constraints, key_constraints, foreign_keys, foreign_key_columns, sql_dependencies, indexes and index_columns. Note that some of the type values that are displayed in the query is not derived from the catalog views they are just constants I came up with for the display purpose. This solution also shows how to use a Common-Table Expression (CTE) to simplify complex queries. This query can be put in a view and used.

Lastly, the solution is by no means complete. There are other objects that can depend on the column like full-text indexes, table-valued functions, chain of dependencies if the view on the column is referenced by another for example and so on. I will leave those as exercise for users to try and implement.

Umachandar Jayachandran