Catalog Views on SQL Server Scripts

System-Versioned (Temporal) Tables in SQL Server

Fri, 19 Jun 2026 00:00:00 +0000

Every UPDATE and DELETE on a system-versioned table leaves behind a complete, queryable history of the previous row — automatically, with no triggers and no audit-table plumbing. SQL Server records the period each row version was valid and answers point-in-time questions through a single FOR SYSTEM_TIME clause. This is the temporal-tables feature, available since SQL Server 2016.

Purpose and Overview

A system-versioned temporal table is a user table that keeps a full history of data changes so you can analyze the data as it existed at any point in the past, not just as it is now. The feature is implemented as a pair of tables: the current table holds the present rows, and a linked history table stores prior versions. The Database Engine manages the relationship — on every update or delete, it closes the old row in the history table and stamps a new period of validity.

SQL Server Database Schema and Data Dictionary Queries

Thu, 18 Jun 2026 00:00:00 +0000

Documenting a database starts with a data dictionary: every table, every column, its data type, length, nullability, and default. SQL Server exposes this through the ANSI-standard INFORMATION_SCHEMA views, which produce a portable schema report that reads almost like English and runs unchanged on other ISO-compliant database engines.

Purpose and Overview

INFORMATION_SCHEMA is a set of views defined by the ISO SQL standard and implemented in a special schema present in every SQL Server database. Their purpose is insulation: they present an internal, system-table-independent view of metadata, so applications keep working even when the underlying system tables change between releases. That portability is the main reason to reach for them — a data-dictionary query written against INFORMATION_SCHEMA will run on SQL Server, PostgreSQL, MySQL, and other engines that implement the standard.

sp_pkeys and Primary Key Metadata in SQL Server

Tue, 16 Jun 2026 00:00:00 +0000

Which columns make up a table's primary key, and in what order are they declared? For a single table, the system stored procedure sp_pkeys answers in one line; for a database-wide inventory, the catalog views behind it give you full control. This post covers both, from the quick lookup to the complete metadata query.

Purpose and Overview

sp_pkeys returns primary key information for one table in the current database. It is an ODBC-catalog procedure — the T-SQL equivalent of the SQLPrimaryKeys ODBC function — and its result set is deliberately compact: TABLE_QUALIFIER, TABLE_OWNER, TABLE_NAME, COLUMN_NAME, KEY_SEQ, and PK_NAME. The KEY_SEQ column is the one that matters most: it gives the sequence number of each column within a multicolumn primary key, so a composite key returns one row per column in declared order.

sysindexes vs sys.indexes: Legacy and Modern Catalog Views

Mon, 15 Jun 2026 00:00:00 +0000

Plenty of SQL Server scripts still in circulation read rowcnt and dpages straight out of sysindexes — a habit inherited from SQL Server 2000, where that table was the canonical place to find row counts and page totals. The object survives only as the sys.sysindexes compatibility view, is flagged for removal, and returns inaccurate numbers for partitioned tables. This post shows the modern replacement and how to migrate.

Purpose and Overview

In SQL Server 2000, sysindexes was a real system table with one row per index and heap, and DBAs leaned on its rowcnt, dpages, reserved, and used columns for quick size and row-count reports. SQL Server 2005 rebuilt the metadata layer, and sysindexes was retained only as sys.sysindexes, a backward-compatibility view. Microsoft's documentation is explicit: this feature is included for backward compatibility, will be removed in a future version, and should not be used in new development.

SQL Server Catalog Views: sys.tables, sys.indexes, sys.objects

Sun, 14 Jun 2026 00:00:00 +0000

The sys catalog views are the supported, forward-compatible way to read SQL Server metadata, and three of them — sys.objects, sys.tables, and sys.indexes — answer most day-to-day questions about what lives in a database. This script joins them into one inventory of every user table, its schema, its row count, and each index defined on it.

Purpose and Overview

sys.objects is the base catalog view: it contains one row for every user-defined, schema-scoped object in a database — tables, views, stored procedures, functions, constraints, triggers, and more — each identified by a unique object_id. sys.tables is a derived view built on top of it. It returns every column sys.objects returns, plus table-specific columns such as temporal_type and is_memory_optimized, but only for rows where the object is a user table. sys.indexes then carries one row per index or heap of each tabular object, keyed back to the table by object_id.