THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Merrill Aldrich

Technical content about Microsoft data technologies. All opinions expressed are purely my own and do not reflect positions of my employer or associates.

Worst possible SQL Server object name?

I currently test any dynamic sql I have to write against objects called

Patt [Y.] O'Furniture

It seems to catch the most obvious problems composing SQL on the fly, aside from name length. (Pity the person grappling with a 128 character object name!) What's the worst object name you've had to deal with?

Published Monday, October 19, 2009 2:44 PM by merrillaldrich
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Boyan Penev said:

Select [Select]

From [From]

Where [Where] = 'Where'

And [nvarchar(50)] = 'nvarchar(50)'

And [int] = 1

October 19, 2009 5:38 PM

merrillaldrich said:

Nice. Makes my brain cramp.

October 19, 2009 5:54 PM

Aaron Bertrand said:

I find that people in general are pretty good at avoiding bad characters in object names, either because they are smart about it, or because they get bitten pretty quickly if they also don't follow other good habits (like using QUOTENAME() when composing dynamic SQL.  I could com up with plenty of fictional examples, but for me, the most troublesome offenses I come across in real life are:

1. Embedded spaces or periods

2. Not descriptive enough

3. Too descriptive

Every time I have to type a tbl, vw or usp prefix, I shudder.  But these are just annoying and redundant, not necessarily problematic per se.

October 19, 2009 5:59 PM

Alexander Kuznetsov said:

in DB2 the following code may work:


might be a valid query in the appropriate context:

create table where(where char(10));

October 19, 2009 6:17 PM

merrillaldrich said:

I guess a table _containing_ SQL injection vulnerabilities could get interesting:

select string from injectionStrings where string = '''; drop table users;'

Think carefully before pressing F5...

October 19, 2009 6:36 PM

Paul Nielsen said:


October 19, 2009 9:09 PM

merrillaldrich said:


Still, I'll take dbo.AccessImport over dbo.AccessLinkedTable any day.

October 19, 2009 9:42 PM

Antony said:

I've always found the GROUP table particularly annoying.

October 20, 2009 8:31 AM

Dan said:

We have a vendor who thinks their clever by naming & grouping their underlying schema like an OO application, "Object.Header" and "Object.Detail"  

If they actually used schemas i'd be happier, but they're all within dbo, so it's hundreds of tables following: dbo.[Object.Detail] etc.  Quite a pain.

October 20, 2009 10:59 AM

Everest said:

How about this one...Celko would probably appreciate:


(iPK int IDENTITY (1,1)

 ,nValue nvarchar (256)


October 20, 2009 9:46 PM

Matt Whitfield said:

Embedded square brackets

CREATE TABLE [[!]]] ([]]] int IDENTITY (1,1) NOT NULL, [[[]]]]] int)

SELECT [[[]]]]], []]] FROM [[!]]]

October 22, 2009 10:33 AM

Anonymous said:

We can take this one step further if you'd like... Don't do this at home, kids:

declare @ table ([[] int)

select [@].[[]

from @ [@]

October 22, 2009 10:39 AM

merrillaldrich said:

Holy ambiguous delimiters, Batman! How do we *escape* these?!

Guys, these are all awesome ^ geekness. But aren't we missing whole realm of possibilities with operators? To wit:

DECLARE @math TABLE ( a INT, b INT, [a + b] INT )

INSERT @math ( a, b, [a + b] ) VALUES ( 2, 2, 5 )

SELECT a, b, [a + b], ( a + b ) AS [a + b] FROM @math  

October 22, 2009 5:17 PM

Armando Prato said:

Damn you, Adam.  That query gave me a headache. ;)

This stuff pales in comparison to column names I've had to deal with like "X" and "Y".  Yes, single character column names.

October 23, 2009 9:51 AM

kriki said:

A database called "tlog".

November 16, 2009 1:23 PM

silk said:^Eescort.html^Eescort.html^Eescort.html^Eescort.html

February 9, 2019 8:48 AM

Leave a Comment


This Blog


Privacy Statement