The LIKE operator in SQL Server allows you to query data using patterns instead of exact matches. Normal select statements using the = operator will only return records where there is an exact match (usually the casing or trailing spaces do not matter). With the LIKE operator, it does not need to be an exact match.

The most basic concept of the like operator is that it allows you to query data without using an exact match in the WHERE clause. It allows you to use some wildcard characters to get the results you are looking for. Here is a basic example:

AnimalID AnimalName AnimalType Animal Weight
35 Giant Squid Fish 400
36 Giant Panda Mammal 500
37 Giant Clam Fish 60

The above statement uses the % as a wildcard. It basically says, show me any animals that start with the word Giant. This would return things like Giant Panda, Giant Squid, and Giant Clam.

Although % is the most common wildcard that is used with LIKE, there are many more. Here is a list of all the allowed wildcards.

Will allow zero or any characters. You can use this before, after, or in-between any string.

AnimalID AnimalName AnimalType Animal Weight
35 Giant Squid Fish 400
36 Giant Panda Mammal 500
37 Giant Clam Fish 60
38 Emperor Penguin Bird 15
39 Hammer Head Shark Fish 90

Will allow any 1 character.

AnimalID AnimalName AnimalType Animal Weight
18 Chicken Bird 5

Will allow 1 character that is specified in the brackets. There are two ways to specify this. [a-d] or [abcd].

The following example will match both goose and moose.

AnimalID AnimalName AnimalType Animal Weight
11 Goose Bird 15
27 Moose Mammal 1000

The following example will match both cat and bat, but it will NOT match rat.

AnimalID AnimalName AnimalType Animal Weight
10 Cat Mammal 10
34 Bat Bird 1

Will match any 1 character that is NOT specified in the brackets. There are two ways to specify this. [^a-d] or [^abcd].

The following example will match horse, but will NOT match zorse… and yes, zorse is an animal… I found it on the internet.

AnimalID AnimalName AnimalType Animal Weight
6 Horse Mammal 750

The following example will match rat, but will NOT match bat or cat.

AnimalID AnimalName AnimalType Animal Weight
33 Rat Mammal 1

If you are comparing a CHAR data type with the like operator, it may not work correctly. This because when you save data to a CHAR field it will space pad the field to the size of the field. To get around this, you need to trim the spaces from the end of the field.

NOT Like
If you want to match where a pattern is NOT like a string, simply put the word NOT in front of the word LIKE.

Escaping The Wildcard
From time to time you will need to actually search for a pattern containing one of the wildcard characters. Let’s say that you wanted to search for anything in a string that had 10% in it. The % (percent symbol) is a reserved word with the LIKE operator. You would search for the % character by using the ESCAPE clause.

In the query above, you can see that !% in the comparison string means to the literal character %. The ESCAPE clause tells the query to not apply the wildcard rules to any character following the specified characters. In this case, we are specifying the ! (exclamation mark).

InvoiceID ItemName LineItemDescription
1 Coupon Code 10% off web coupon


How To Use The OUTPUT Clause


The OUTPUT clause is an amazing part of SQL Server that many people do not know about.  As corny as it is, I still remember the day that I found it.  I had been searching for the whole day trying to figure out how to get the identity values from a large amount of data that I just inserted in to the database.  There had to be a way… right?  After searching and searching, I gave up and just accepted that it is not possible… a few days later I found exactly what I was looking for… the OUTPUT clause.

The OUTPUT clause is a part of the query that will return data from before or after the operations is completed.  Let’s say that you inserted data in to a table and you wanted the ID column values (which are auto-numbers).  The OUTPUT clause gives you this information!  It can work on INSERT, DELETE, UPDATE, and MERGE statements.  I will take you through examples of each.

To access the data that is being altered in your sql statement, you need to use special column prefixes that SQL Server makes available to you.  The two special prefixes are “inserted” and “deleted”.  During an insert statement, the inserted prefix is available for you to use.  During a delete statement, the deleted prefix is available to you.  During the update and merge statements, both the deleted and inserted prefixes are available to you.  In these cases, the deleted represents the data before it was changed and the inserted represents the data after it was changed.

One thing to note is that the data being outputted must go in to a table or table variable.

OUTPUT Clause On An INSERT Statement

OUTPUT Clause On A DELETE Statement

OUTPUT Clause On An UPDATE Statement

OUTPUT Clause On A MERGE Statement



Case Sensitive Compare


Occasionally we need to do a string comparison in SQL Server as a case sensitive compare.  By default, case sensitive compare is not turned on for tables in SQL Server.  It’s actually pretty easy to change a string comparison to a case sensitive compare.  You can do this by using the COLLATE clause.

Read below to find out why this works and other tips on doing a case sensitive compare.

What Is The COLLATE Clause

The COLLATE clause is something that you can add to the end of an expression to set the collation of the operation to a specific collation.  So in the example… the string equal comparison is being changed to a collation of SQL_Latin1_General_CP1_CS_AS.

A collation in SQL Server is something defines how data is compared.  This could be things like case sensitivity, acceptable characters, etc…  Most of the time (for English installations of SQL Server) it will be a collation type of SQL_Latin1_General_CP1_CI_AS.  This is because the Latin character set covers English and other Latin based languages.

The two most common collations that I deal with are SQL_Latin1_General_CP1_CI_AS and SQL_Latin1_General_CP1_CS_AS.  You can see that they are very similar.  In fact… the only difference is the _CI_ and _CS_.  These actually stand for Case-Insensitive and Case-Sensitive.
Field Level Case Sensitivity

Even better… you don’t need to set the collation on every sql statement that you want to make case sensitive.  There is actually a setting that you can apply to a field in a table.

NOTE: that if you are joining on this table, both collations must be the same or you will need to specify the collation to use.

Create a new table with a case sensitive field

Change a table’s column to be case sensitive