In SQL Server Identifiers refers to Database Objects, which are to be distinguished from Variables.

Note that in SQL Server database objects should be delimited by double quotes ("), whereas literals (which may be passed to variables) should be delimited by single quotes (').


Identifiers name nearly every "database" object in SQL Server including the following: Servers, Databases, Tables, Views, Columns, Indexes, Triggers, Procedures, Constraints, and Rules. Most database objects require names, but some, such as constraints, do not.

Identifiers must follow four rules:

  1. The first character must be Unicode letters, A-Z, a-z, _, @, or #.
  2. The following characters can also include 0-9 and $.
  3. The identifier cannot be a Transact-SQL reserved word.
  4. The identifier cannot have an embedded space or special characters.

Identifiers are of data type nvarchar(128). Identifiers that do not follow these rules must be delimited by brackets or double quotes.

[My Table]
-- requires delimiters because of space.

-- requires delimiters because it is reserved word.

-- delimiters not required but can be used anyway.

Depending on how mixed an environment a developer is working, database objects may or may not be qualified. Here are the different ways a database object may be qualified.

[ [ [ server. ] [ DBorCatalog ] . ] [ OwnerOrSchema ] . ] object
server.db.schema.obj -- this is fully qualified

Within a table or view columns can have up to three qualifiers. The variations include:


Database Objects

There cannot be ambiguity when identifying database objects (eg Servers, Databases, Tables, Views, Columns, Indexes, Triggers, Procedures, Constraints, Rules, etc., depending on the DBMS).

Ambiguity may occur if multiple objects have the same name in the system. EG:

  • Two tables may have different columns with the same name.
  • Two users may have different tables with the same name.

To resolve this it is helpful to qualify objects as needed. Here are some possibilities of a database object that goes from unqualified to increasingly qualified to fully qualified:

Field Table.Field Database.Owner.Table.Field Server.Database.Owner.Table.Field

It becomes cumbersome to use qualified database objects all the time. It is useful to use an alias (aka variable, range variable, or correlation name). In the FROM clause for aliased tables or views. EG:

SELECT tblCustomer.Name
FROM MyDatabase.MyOwner.tblCustomer AS Cus
    INNER JOIN MyDatabase.MyOwner.tblOrders As Ord
    ON Cus.Name = Ord.Name
WHERE Ord.Name = 'George'


The following prefixes have special meanings in SQL Server:

  • @. Local variables or parameters start with an @.
  • @@. Global variables and some Transact-SQL functions start with a double-@.
  • #. Temporary tables or procedures start with a #.
  • ##. Global temporary objects start with a double-#.

There are two ways data can be passed between statements:

  1. Transact-SQL Variables can hold data within the batch or stored procedure, i.e. like local scope variables.
  2. Transact-SQL Parameters can input or output data between a stored procedure and the user, i.e. like global scope variables.

DECLARE variables has this syntax:

DECLARE { { @LocalVariable DataType }
| { @CursorVariableName CURSOR }
| { TableTypeDefinition }
} [, ...]

Parameters follow this syntax:

@parameterName datatype [= default] [OUTPUT]

Note that the default value can include wildcards (EG: % and _) that can be used with SQL keywords such as LIKE.

This example shows a local variable and two parameters: one for input and another for output.

CREATE PROCEDURE myStoredProcedure
@InputParameter int, @OutputParameter int OUTPUT

DECLARE  @LocalVariable INT
SET @LocalVariable = 2

WHERE Field = @InputParameter/@LocalVariable

SELECT @OutputParameter = MAX(Field)

GeorgeHernandez.comSome rights reserved