Emojis in SQL Server
13September 15, 2016 by Kenneth Fisher
I blame Aaron Bertrand (b/t) and Kevin Kline (b/t). Aaron who posted a great #BackToBasics blog about naming stored procedures and Kevin who tweeted about it.
It’s not my fault. I had to be sarcastic. I had to mention the correct naming standard for stored procedures.
usp_DBAName_GUID_purpose_GUID2_createdate_VersionNumber
It’s certainly not my fault I made a flip comment about emoji’s in SQL Server. It’s entirly Aaron’s for showing me it could be done. But now I just have to use them.
Introducing my new comment block.
I copied and pasted the emoji’s from here. Oh, and here is my new test database.
CREATE DATABASE [😺&🐯&🐻o🙋]
You can see how it’s all Aaron and Kevin’s fault right?
Edit:
Ok, this seemed like an important quick addition to this post:
¯\_(ツ)_/¯
SQL Studies 
Go on, what does sp_MSforeachDB make of that?
Actually it would work just fine if you do this [?]. Of course sp_MSforeachDB is pretty buggy anyway.
You are one sick person.
I can’t wait to mess with the developers. 🙂
I’m going to take that as a compliment. Of course there are LOTS of ways to mess with developers.
As this was SQL Sentry (Aaron) I would like to see what Plan Explorer would make of the execution plans.
Off guess it wouldn’t care at all. It’s just like any other unicode value.
Honestly, from a testing POV, this convention should be adopted by the companies that make tools. If your tool doesn’t choke on those names, then it won’t choke on “lest robust” ones
Not a bad idea. Same reason I use a case sensitive testing environment.
[…] delimiters around it depending on what the name is. Identifiers with spaces, special characters or emojis require delimiters, otherwise it’s optional. If it does you will use square brackets ([]) or […]
Hi Ken. While it is true that Emojis can be used (really it’s all but 2 Unicode characters), a caveat / note of caution needs to be added here: SQL Server Collations and non-versioned Windows Collations (well, version number not in the name, which implies version 80 / SQL Server 2000) assign no sort weights to any supplementary characters. Emojis are supplementary characters. This means that using them in one object name at a particular level is usually not an issue, but using multiples of them increases the chances of it becoming an issue since all names of a particular item need to be unique. So using 1 of them or 100 of them is the same as using none of them. They simply do not count in those two early sets of Collations, unless they are binary Collations. It is not until the version 90 Collations (those introduced with SQL Server 2005) were they given sort weights and could be distinguished from each other outside of binary collations. For examples and proof of this, please see the “Supplementary Characters” section of the following post:
That’s great information since I’m actually using them in on of my demo databases. As object names so it shouldn’t be as big a deal, but still. But honestly if I ever saw someone using emojis in anything but a “play” database I’d be seriously worried about them in general.
This isn’t just an issue for database names, it’s for anything. The difference is that server-level objects (Databases, Logins, tempdb meta-data, variable and cursor names, etc) are controlled by the Instance/Server Collation, while Database-level objects (Users, Schemas, Schema-bound objects, etc) are controlled by the Database’s default Collation. And given that we create more objects at the DB level than at the server level, it is actually more likely that you will have an issue with DB objects (but again, only if you are using Collations that pre-date the 90 series).
Also, while emojis are the most fun / common to be dealing with (especially in examples like we have both given), there are a great many valid, non-emoji Supplementary Characters, even if they are infrequently used.
[…] Notice anything here? Working with automation is a lot like working with dynamic SQL. You aren’t going to be sitting there watching it and you have very limited control over the inputs. Once you have a piece of code that works on your limited set of examples you need to make sure it works on every possible input. If you are working with database names you have to account for spaces in the names, symbols, hidden characters, even emojis. […]