Home/ Questions/Q 586487
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T15:06:44+00:00

Assume SQL Server 2005+. Part A: What is the canonical way to query from

  • 0

Assume SQL Server 2005+.

Part A:

What is the canonical way to query from the system/internal/meta/whatever tables/views (sorry, not a database ninja) for any user table or column names that use SQL Server keywords (like case)?

I don’t mind maintaining the list of keywords if that’s not query-able, as it only changes with versions of SQL Server supported (right?).

Looking at available views in SQL Server 2005, I can easily enough query this information from INFORMATION_SCHEMA.COLUMNS and INFORMATION_SCHEMA.TABLES, but I want to be sure it’s from the best possible location for future-proofing.

Part B:

Is it possible to get the list of keywords via query?

UPDATE: While a useful concept, I’m specifically not interested in escaping the column/table/etc names in question because I’m hoping to write a tool that will check for tables/columns/etc that share names with keywords and provide useful warnings to developers. The tool would be used during code reviews at my office to point out that the developer might want to consider renaming the entity. (Or hopefully by the developer before code reviews for their own good!) I may even set it up for use with continuous integration in my build scripts, but that’s only a thought for the future.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You should properly quote the names used. If you generate code, use the built-in QUOTENAME function. Don’t build a list of known keywords, instead quote every name used for every object, including database name, schema name and object name. Also make sure you always adhere to the correct case of the objects involved. As a best practice, develop on a case sensitive collation server instance. Developing code on case insensitive server collation (default) can lead to embarasing failures on production when deployed on case sensitive collation servers.

    For Part A

    Personally I would go for sys.columns and sys.objects actually. INFORMATION_SCHEMA views are also good, and they’re ‘portable’ in theory, I’m just so much more used to the SQL specific ones though. I choose sys.objects vs. sys.tables because it covers more (eg. views). I would suggest you also cover table valued functions, table valued parameter types (in 2008 only) and temporary #tables and table @variables declared inside stored procedures. That would leave out only temp #tables and table @variables declared in batches sent by clients, but those are basically in client code only.

    • 0