SA0043A : Avoid using reserved words for type names |
![]() |
Avoid using reserved words as user-defined type names in SQL Server.

Using reserved words as names for user-defined types can create confusion and decrease code readability. This problem is particularly relevant in T-SQL and SQL Server contexts where readability and maintainability are crucial.
For example:
1-- Problematic use of a reserved word as a user-defined type name 2CREATE TYPE [SELECT] AS TABLE (Column1 INT);
This example is problematic because SELECT is a reserved word in SQL Server. Using it as a user-defined type name can lead to misunderstandings, especially for individuals reading or maintaining the code who might expect it to relate to the SQL SELECT statement.
-
Difficulties in understanding the purpose and functionality of the code, particularly for new developers or those unfamiliar with the database design.
-
Potential conflicts and errors when the code is modified or extended, as reserved words have predefined meanings in SQL.

Resolve issues related to the use of reserved keywords as user-defined type names by renaming the types to improve code readability and prevent potential conflicts.
Follow these steps to address the issue:
-
Identify the user-defined types that use reserved keywords as their names by reviewing the types reported by the analysis rule.
-
Rename these user-defined types to avoid using reserved keywords. Choose names that clearly reflect their intended purpose and are not part of SQL Server’s reserved keywords. For instance, instead of using SELECT, consider a more descriptive name like OrderSelectionType.
-
Update all references to the renamed types in your database schema and application code to maintain functionality and consistency.
For example:
1-- Example of renaming a type with a reserved keyword 2-- Before renaming 3CREATE TYPE [SELECT] AS TABLE (Column1 INT); 4 5-- After renaming 6CREATE TYPE OrderSelectionType AS TABLE (Column1 INT);

The rule has a ContextOnly scope and is applied only on current server and database schema.

Rule has no parameters.

The rule requires Analysis Context. If context is missing, the rule will be skipped during analysis.


Naming Rules, Code Smells

There is no additional info for this rule.
