QUOTENAME Object Names: Quote Each SQL Server Name Part

QUOTENAME object names separately to keep each part of a qualified SQL Server name intact. The function surrounds its entire input with identifier delimiters. A dot inside that input stays inside one quoted name. I keep the schema and object in separate variables.

QUOTENAME object names separately

I start with a schema and an object name. Quoting their combined string produces one identifier containing a dot. Quoting each part produces a schema-qualified name. Spaces inside the object part remain intact.

DECLARE @SchemaPart sysname=N'dbo', @ObjectPart sysname=N'Sales Details';
SELECT QUOTENAME(@SchemaPart+N'.'+@ObjectPart) AS WholeInputQuoted,
       QUOTENAME(@SchemaPart)+N'.'+QUOTENAME(@ObjectPart) AS EachPartQuoted;

The expected strings are [dbo.Sales Details] and [dbo].[Sales Details]. Their brackets give them different structures. These examples return strings without executing them. Neither result proves that an object exists.

Let QUOTENAME escape the closing bracket

A closing bracket inside a name needs escaping. QUOTENAME doubles that bracket before adding the outside delimiters. I let the function perform that step. Adding brackets by hand leaves this input broken.

DECLARE @ObjectPart sysname=N'Sales]Archive';
SELECT QUOTENAME(@ObjectPart) AS QuotedPart;

The expected quoted part is [Sales]]Archive]. The doubled bracket belongs to the object name. It doesn’t finish the quoted identifier early. I retain the unquoted part separately when the application needs its original spelling.

Check the QUOTENAME object names length boundary

QUOTENAME accepts at most 128 characters. Longer input returns NULL. An unsupported delimiter also returns NULL. I check both outcomes before using a returned name.

DECLARE @Input nvarchar(129)=REPLICATE(N'A',129);
SELECT QUOTENAME(@Input) AS TooLongInput,
       QUOTENAME(N'Orders',N'x') AS UnsupportedDelimiter;

Both results are expected to be NULL. The input variable allows 129 characters, so it preserves the overlong test. A sysname variable would narrow that input before the function received it. Widening only the output cannot restore lost input.

A dot can belong to one object part

An object name can itself contain a dot. I preserve that dot inside the object’s brackets. The separator between schema and object remains outside them. This distinction disappears when I split every dot without understanding the input.

DECLARE @ObjectPart sysname=N'Order.Header';
SELECT QUOTENAME(N'dbo')+N'.'+QUOTENAME(@ObjectPart) AS QualifiedName;

The expected output is [dbo].[Order.Header]. This example starts with separate, known parts. It doesn’t parse a caller’s multipart string. That parsing task needs its own input contract.

Quoting does not approve a name

It’s tempting to treat a quoted name as approved input. I still check whether the requested object belongs to the operation’s allowed set. Quoting protects identifier syntax. It doesn’t grant access or approve arbitrary SQL fragments.

Ordinary filter values belong in parameters when a statement executes. They aren’t object names to wrap in brackets. The examples here never execute generated text. That keeps the output contract easy to inspect.

Keep the returned string wide enough

QUOTENAME returns nvarchar(258). A 128-character input consisting entirely of closing brackets reaches that output length. Each closing bracket doubles, and the function adds two outside delimiters. I don’t store that result in a sysname variable.

For a two-part name, I allow room for both quoted parts and the separating dot. I also test NULL before combining the parts. A valid quoted string still needs the correct receiving type. The input limit and output width solve different problems.

Run the exact output checks

This last block shows all three name pairs side by side, then the input boundary, the maximum bracket expansion and the NULL results in one grid. It shows spelling and length, including every delimiter. Quoting does not execute the returned text.

SELECT v.CaseName,QUOTENAME(v.SchemaPart+N'.'+v.ObjectPart) AS WholeInputQuoted,
       QUOTENAME(v.SchemaPart)+N'.'+QUOTENAME(v.ObjectPart) AS EachPartQuoted
FROM (VALUES (1,N'Space inside one part',N'dbo',N'Sales Details'),
             (2,N'Right bracket',N'dbo',N'Sales]Archive'),
             (3,N'Dot inside one part',N'dbo',N'Order.Header'))
     AS v(CaseNo,CaseName,SchemaPart,ObjectPart)
ORDER BY v.CaseNo;
DECLARE @AtLimit nvarchar(129)=REPLICATE(N'A',128),
        @TooLong nvarchar(129)=REPLICATE(N'A',129),
        @ManyBrackets nvarchar(128)=REPLICATE(N']',128);
SELECT 128 AS InputCharacters,LEN(QUOTENAME(@AtLimit)) AS OutputCharacters,
       DATALENGTH(QUOTENAME(@AtLimit)) AS OutputBytes,
       CASE WHEN QUOTENAME(@TooLong) IS NULL THEN 1 ELSE 0 END AS Input129IsNull,
       CASE WHEN QUOTENAME(N'Orders',N'x') IS NULL THEN 1 ELSE 0 END AS BadDelimiterIsNull,
       LEN(QUOTENAME(@ManyBrackets)) AS MaximumEscapedCharacters;

My SQL Server 2025 run matched all three name pairs. The 128-character A input produced 130 characters and 260 bytes. The 129-character input and unsupported delimiter returned NULL. An input of 128 closing brackets produced 258 characters.

Quote each part on its own, and let the function do the escaping.

A quoted name is not an approved operation, it is one identifier with explicit boundaries.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.