| title | System Compatibility Views (Transact-SQL) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| description | System Compatibility Views (Transact-SQL) | ||||||||||
| author | rwestMSFT | ||||||||||
| ms.author | randolphwest | ||||||||||
| ms.date | 03/14/2017 | ||||||||||
| ms.service | sql | ||||||||||
| ms.subservice | system-objects | ||||||||||
| ms.topic | reference | ||||||||||
| ms.custom |
|
||||||||||
| helpviewer_keywords |
|
||||||||||
| dev_langs |
|
||||||||||
| monikerRange | >=aps-pdw-2016 || =azuresqldb-current || =azure-sqldw-latest || >=sql-server-2016 || >=sql-server-linux-2017 || =azuresqldb-mi-current || =fabric || =fabric-sqldb |
[!INCLUDEsql-asdb-asdbmi-asa-pdw-fabricse-fabricdw-fabricsqldb]
Many of the system tables from earlier releases of [!INCLUDEssNoVersion] are now implemented as a set of views. These views are known as compatibility views, and they are meant for backward compatibility only. The compatibility views expose the same metadata that was available in [!INCLUDEssVersion2000]. However, the compatibility views do not expose any of the metadata related to features that are introduced in [!INCLUDEssVersion2005] and later. Therefore, when you use new features, such as [!INCLUDEssSB] or partitioning, you must switch to using the catalog views.
Another reason for upgrading to the catalog views is that compatibility view columns that store user IDs and type IDs may return NULL or trigger arithmetic overflows. This is because you can create more than 32,767 users, groups, and roles, and 32,767 data types. For example, if you were to create 32,768 users, and then run the following query: SELECT * FROM sys.sysusers. If ARITHABORT is set to ON, the query fails with an arithmetic overflow error. If ARITHABORT is set to OFF, the uid column returns NULL.
To avoid these problems, we recommend that you use the new catalog views that can handle the increased number of user IDs and type IDs. The following table lists the columns that are subject to this overflow.
| Column name | Compatibility view | SQL Server 2005 view |
|---|---|---|
| xusertype | syscolumns | sys.columns |
| usertype | syscolumns | sys.columns |
| memberuid | sysmembers | sys.database_role_members |
| groupuid | sysmembers | sys.database_role_members |
| uid | sysobjects | sys.objects |
| uid | sysprotects | sys.database_permissions sys.server_permissions |
| grantor | sysprotects | sys.database_permissions sys.server_permissions |
| xusertype | systypes | sys.types |
| uid | systypes | sys.types |
| uid | sysusers | sys.database_principals |
| altuid | sysusers | sys.database_principals |
| gid | sysusers | sys.database_principals |
| uid | syscacheobjects | sys.dm_exec_plan_attributes |
| uid | sysprocesses | sys.dm_exec_requests |
When referenced in a user database, system tables which were announced as deprecated in SQL Server 2000 (such as syslanguages or syscacheobjects), are now bound to the back-compatibility view in the sys schema. Since the SQL Server 2000 system tables have been deprecated for multiple versions, this change is not considered a breaking change.
Example: If a user creates a user-table called syslanguages in a user-database, in SQL Server 2008, the statement SELECT * from dbo.syslanguages; in that database would return the values from the user table. Beginning in SQL Server 2012, this practice will return data from the system view sys.syslanguages.
Catalog Views (Transact-SQL)
Mapping System Tables to System Views (Transact-SQL)