- Exploring the Server
- Learning About Tables
- Learning About Fields
- An Example
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Learning About Tables
After you know what databases are available on the server, you can look for information about the tables in a database. The following sections describe stored procedures that describe tables.
Note that the program must be using a database before it can execute these procedures. For example, to use the sp_tables procedure to see what tables are in the TestScores database, the program must be connected to the TestScores database. A simple SQL script to use the TestScores database and then execute the sp_tables procedure would look like this:
USE TestScores; sp_tables;
sp_tables
The sp_tables stored procedure lists the tables in a database. For example, the sp_tables statement produces the following output for the TestScores database.
TABLE_QUALIFIER TABLE_OWNER TABLE_NAME TABLE_TYPE REMARKS =============== =========== =================== ============ ======= TestScores dbo syscolumns SYSTEM TABLE NULL TestScores dbo syscomments SYSTEM TABLE NULL TestScores dbo sysdepends SYSTEM TABLE NULL TestScores dbo sysfilegroups SYSTEM TABLE NULL TestScores dbo sysfiles SYSTEM TABLE NULL TestScores dbo sysfiles1 SYSTEM TABLE NULL TestScores dbo sysforeignkeys SYSTEM TABLE NULL TestScores dbo sysfulltextcatalogs SYSTEM TABLE NULL TestScores dbo sysfulltextnotify SYSTEM TABLE NULL TestScores dbo sysindexes SYSTEM TABLE NULL TestScores dbo sysindexkeys SYSTEM TABLE NULL TestScores dbo sysmembers SYSTEM TABLE NULL TestScores dbo sysobjects SYSTEM TABLE NULL TestScores dbo syspermissions SYSTEM TABLE NULL TestScores dbo sysproperties SYSTEM TABLE NULL TestScores dbo sysprotects SYSTEM TABLE NULL TestScores dbo sysreferences SYSTEM TABLE NULL TestScores dbo systypes SYSTEM TABLE NULL TestScores dbo sysusers SYSTEM TABLE NULL TestScores dbo Students TABLE NULL TestScores dbo TestScores TABLE NULL TestScores dbo sysconstraints VIEW NULL TestScores dbo syssegments VIEW NULL
Of the tables shown, I created only the Students and TestScores tables. All of the others are automatically created by the database. Those tables contain information about the database itself. You can query these tables directly to learn more about the database, although it is often easier to find a stored procedure to make the query for you.
sp_pkeys
The sp_pkeys stored procedure gives information about a table's primary key. For example, the statement sp_keys TestScores returns the following results.
TABLE_QUALIFIER TABLE_OWNER TABLE_NAME COLUMN_NAME KEY_SEQ PK_NAME =============== =========== ========== =========== ======= ============= TestScores dbo TestScores StudentId 1 pk_TestScores TestScores dbo TestScores TestNumber 2 pk_TestScores
This output indicates that the TestScores table's primary key consists of the StudentId and TestNumber fields. The KEY_SEQ field gives you the ordering of the fields within the key.
sp_fkeys
The sp_fkeys stored procedure gives information about a table's foreign keys. This procedure returns a lot of fields so they are not all shown here. Probably the most important fields are PKTABLE_NAME, PKCOLUMN_NAME, FKTABLE_NAME, and FKCOLUMN_NAME. These fields give the names of the primary and foreign tables and their related columns. The KEY_SEQ field gives the ordering of the fields if they are in a sequence that must match. For example, if the FirstName and LastName fields in one table must match the FName and LName fields in another table, KEY_SEQ tells you how to order the fields.
The following text shows these columns in the results for the statement sp_fkeys Students executed on the test database.
PKTABLE_NAME PKCOLUMN_NAME FKTABLE_NAME FKCOLUMN_NAME KEY_SEQ ============ ============= ============ ============= ======= Students StudentId TestScores StudentId 1
sp_helpconstraint
The sp_helpconstraint stored procedure returns information about a table's CHECK and foreign key constraints. The following output shows the result of the SQL statement sp_helpconstraints TestScores with some of the less-interesting fields removed. The results identify the TestScores table's CHECK constraint, the fact that its StudentId field is related to the Students table's StudentId field, and the primary key that includes the StudentId and TestNumber fields.
constraint_type constraint_keys
======================= ==============================================
CHECK on column Score ([Score] >= 0 and [Score] <= 100)
FOREIGN KEY StudentId
REFERENCES TestScores.dbo.Students (StudentId)
PRIMARY KEY (clustered) StudentId, TestNumber
sp_helpindex
The sp_helpindex stored procedure gives information about a table's indexes. The statement sp_helpindex Students generated the following output. This result describes the Student table's UNIQUE constraint on the LastName/FirstName field combination and the primary key on the StudentId field.
If you refer to the earlier "Test Database" section, you can examine the SQL script that created the TestScores database. The Students table's CREATE TABLE statement explicitly gives its UNIQUE constraint the name con_Students_Names. The sp_helpindex procedure correctly lists that index name.
The CREATE TABLE statement marked the StudentId field as the table's primary key, but did not name it. In cases like that, the database automatically creates an index name. In this case, it is named PK__Students__182C9B23. While distinctive, this is not a very memorable name. If you will need to explicitly manipulate an index later with your code, give it a more meaningful name when you create it.
index_name index_description index_keys ====================== =================================================== =================== con_Students_Names nonclustered, unique, unique key located on PRIMARY FirstName, LastName PK__Students__182C9B23 clustered, unique, primary key located on PRIMARY StudentId