The two are actioned via very similar syntax, but operate slightly differently. Auto is probably named “Auto” because it performs a lot of the XML node naming for you. There are also a couple of other differences which I’ll explain in this post.

With FOR XML AUTO, you don’t have the ability to name your row’s like you do in RAW. This is because their names are derived from the aliases given to the tables in your query. For example, having a table named Person, and using FOR XML AUTO against this table would give your rows a name of “Person”. This is the same as using FOR XML RAW(‘Person’), see below for a literal example of this:

SELECT * FROM Person
FOR XML AUTO

SELECT * FROM Person
FOR XML RAW('Person')

Both of the above examples would return the below XML:

<Person PersonId="1" Name="Zach Stagers" Age="22" />

As with RAW, you can specify your root element in AUTO:

SELECT * FROM Person
FOR XML AUTO, ROOT('People')

The above would return the exact same XML data, but with the specified root element wrapped around it.

<People>
 <Person PersonId="1" Name="Zach Stagers" Age="22" />
</People>

The attributes of the person row can further be split out into their own elements by specifying ELEMENTS, and can also be given a namespace and the ability to handle SQL NULL‘s by specifying XSINIL

SELECT * FROM Person
FOR XML AUTO, ROOT('People'), ELEMENTS, XSINIL

The above example would return:

<People xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <Person>
  <PersonId>1</PersonId>
  <Name>Zach Stagers</Name>
  <Age>22</Age>
 </Person>
</People>

There are a couple of other things to remember when using FOR XML AUTO, and that is that the order of your XML elements is down the order in which your columns are specified. For example, executing the below two queries would give you the same information, but using them with FOR XML AUTO will give you completely different XML:

SELECT Person.Name,
       Orders.Item
 
FROM Person 
     JOIN Orders ON Orders.PersonId = Person.PersonId
 
FOR XML AUTO, ROOT('PeopleWithOrders')

Returns:

<PeopleWithOrders>
 <Person Name="Zach Stagers">
  <Orders Item="Bike" />
  <Orders Item="Laptop" />
  <Orders Item="Phone" />
 </Person>
</PeopleWithOrders>

SELECT Orders.Item,
       Person.Name
 
FROM Person 
     JOIN Orders ON Orders.PersonId = Person.PersonId
 
FOR XML AUTO, ROOT('PeopleWithOrders')

The above query, with the columns swapped over will return:

<PeopleWithOrders>
 <Orders Item="Bike">
  <Person Name="Zach Stagers" />
 </Orders>
 <Orders Item="Laptop">
  <Person Name="Zach Stagers" />
 </Orders>
 <Orders Item="Phone">
  <Person Name="Zach Stagers" />
 </Orders>
</PeopleWithOrders>

So, you just need to remember that the order of the columns is what specifies the output of your XML, not the order of the tables in the FROM clause. The names given to the tables, however, specifies the names given to the XML nodes.

                          

In this post, I’ll show you how to write a very simple Recursive CTE, and explain how it works.

The example that I’ll be working with in this post is as below:

;WITH RCTE AS
       (
        SELECT 1 AS [Recursion Level], 'A' [Type]
 
        UNION ALL
 
        SELECT [Recursion Level] +1 AS [Recursion Level], 'R' [Type]
        FROM RCTE
        WHERE [Recursion Level] < 5
       )
 
SELECT * FROM RCTE
OPTION(MAXRECURSION 4)

This example obviously has no practical use, but it’s good for showing how a Recursive CTE works.

The query starts in the exact same way as a normal CTE, ;WITH RCTE AS. The semicolon terminates any SQL defined before the CTE, and it’s best practice to add a semicolon here for that reason. If any preceding code (Commonly the declaration of variables) isn’t terminated by a semicolon, an error will occur.

The second line, SELECT 1 AS [Recursion Level], ‘A’ [Type] is known as the “Anchor Member”. This query defines the base level item that you would like to build upon. This simple select just creates a single record with two columns.

UNION ALL joins the two parts of the recursive query together, and must be defined after your anchor query.

The query defined after the UNION ALL is known as the “Recursive Member”. This query must reference the CTE in its FROM clause. This is so the query knows what base values it has, and can therefore build upon. The where clause, WHERE [Recursion Level] < 5, is a terminator statement, which stops the query from looping indefinitely. The CTE is then closed off with a closing a bracket.

A simple SELECT * FROM RCTE is all that is needed to pull back all of the required information from the CTE in this example.

OPTION(MAXRECURSION 4) is essentially another safety net to stop the query from spiralling into an infinite loop. This stops the query from running at a maximum of 4 recursions, but be aware that if 4 recursions isn't enough to extract all of the data within the loop - an error will occur. For example, If I changed my WHERE clause to less than 6 in the Recursive Member, and left my Max Recursion option at 4 I would recieve the following error:

The statement terminated. The maximum recursion 4 has been exhausted before statement completion.

The Max Recursion clause is optional.

The result set from the example query would like the below:

Recursive CTE Result

As you can see, 5 results were returned – even though WHERE [Recursion Level] < 5 was specified in the Recursive Member, and OPTION(MAXRECURSION 4) is defined in the outer query. This is because the Anchor Member (First record in the result set, type “A”) doesn’t count as a recursion. There are, however, 4 recursion records (type “R”).

A more practical use of a Recursive CTE would be to build something like a family tree, or a companies employee structure.

                          

Now, after a fair amount of googling, there appears to be plenty of information on how to set up an instance of SQL server to listen for traffic on another port – but barely anything about how to actually connect SSMS to it! So I decided to write something quick and simple about how to do it!

It’s still just as simple as the IP:Port, but instead of using a colon like most things, it’s a comma.

SQL Login Port Specification

                          

To choose the colour option that you’d like, open Microsoft Excel > Click File > Options (Near the bottom in the menu on the left hand side) > On the General tab you can select your colour scheme:

Excel Colour Theme

                          

They can be applied to a single column, or across multiple columns (A maximum of 16). Any column or combination of columns referenced by the Primary Key will be unique, and because of this, they’re usually chosen as the Identity column as well.

A Primary Key column cannot be nullable, due to the fact that it forces uniqueness in the table. Computed columns are allowed to be used as a Primary Key.

When a Primary Key is created, the columns it’s created on also have a clustered index created on them. If you’d like to override this functionality, you can do so by specifying NONCLUSTERED during the creation of the key.

Adding a Primary Key Constraint to an existing table

ALTER TABLE Products
ADD PRIMARY KEY (ProductId)

The above code will modify the Products table to add a Primary Key Constraint to the ProductId column.

ALTER TABLE Products
ADD PRIMARY KEY NONCLUSTERED (ProductId, ProductName)

The above code will modify the Products table to add a Primary Key Constraint across two columns, but also overrides the default action of creating a clustered composite index, and creates a nonclustered composite index instead. What do I mean by composite? This means that the index references multiple columns.

Adding a Primary Key Constraint during table creation

CREATE TABLE Products 
  (
   ProductId INT PRIMARY KEY IDENTITY,
   ProductName VARCHAR(50))

In the above example, we’re adding the Primary Key to the integer column ProductId. The same column is also being specified as the identity column for the table, as I mentioned earlier, this is fairly common.

Removing a Primary Key Constraint

A table can only ever have one Primary Key, and you may reassess your needs and have to drop the existing Primary Key.

In order to do this, you’ll first need to find the name of the primary key that you’d like to drop. You can do this by executing the below code (replace “Schema.Table” with your details, but keep the single quotes):

SELECT I.name [PrimaryKeyName]
 
FROM sys.tables T 
     JOIN sys.indexes I ON I.OBJECT_ID = T.OBJECT_ID
 
WHERE T.OBJECT_ID = OBJECT_ID('Schema.Table') 
      AND I.is_primary_key = 1

Once you’ve run the above code, and the name has been returned, you can run the below code to drop the Primary Key:

ALTER TABLE table_name
DROP CONSTRAINT primary_key_constraint_name

                          

CASE
 WHEN Column1 = 'Seven' THEN 7
 WHEN Column1 = 'Eight' THEN 8
 ELSE 0
 END AS [Number]

The above syntax would be used within a select statement, and would be placed along side all other columns in your column list. This example would check all data returned from Column1, if it finds the word ‘Seven’ then the number 7 will be returned in its place, the same goes for ‘Eight’ and 8. Anything that does not equal ‘Seven’ or ‘Eight’ will be returned as a 0.

As many WHEN lines can be written as are necessary.

It’s possible to nest Case statements up to a maximum of 10 levels deep.

Case Statements can also be used within Where clauses, which is particulary useful within a parameterized stored procedure.

For example, if you had a parameter of @Cost, then your Where clause may look like this:

WHERE CASE
       WHEN @Cost = 'All' THEN 1
       WHEN @Cost = 'None' AND Column1 IS NULL THEN 1
       WHEN @Cost NOT IN ('All', 'None') AND Column1 = CONVERT(INT, @Cost) THEN 1
       ELSE 0
       END = 1

The above example is checking the value of our Varchar parameter @Cost, then performing any search functionality that goes along with it.

When @Cost is All, there is no other search critiria written as we want to return everything. When @Cost is None, then we only want to return columns with a NULL entry, so we check that @Cost is ‘None’ and our Column1 IS NULL.

When we want to work with the @Cost parameter as an INT, we have to explicitly define that it’s not All or None, then specify our search “Column1 = Covert(INT, @Cost)”. If we do not explicitly define that we are no longer searching for All or None within @Cost, an error will occur for trying to compare an Int and a Varchar value.

The last use of the CASE statement that I’d like to mention is within an UPDATE statement. You can use the CASE to define what value should be set depending on the value of another column, for example:

UPDATE Table1
SET Column1 = CASE 
               WHEN Column2 = 'Seven' THEN 7
               WHEN Column2 = 'Eight' THEN 8
               END
WHERE Column1 IS NULL

                          

For example, I like all of my SQL keywords to be written in upper case letters, so if I find one that isn’t in a colleagues code – I simply highlight the text with my cursor then press CTRL + SHIFT + U to make all of the letters upper case.

The reverse of this, should you ever need to make letters lower case is CTRL + SHIFT + L.

                          

Start off by highlighting the range of data that you would like to find the distinct values in, I’ll be using the below simple sample data for the purpose of this post:

Example Data

On the “Data” tab of Excel 2010, find the “Remove Duplicates” button:

Click the button, and the Remove Duplicates Dialogue will appear:

Remove Duplicates Dialogue

On the top right of the Remove Duplicates Dialogue box, you’ll see a check box – “My data has headers” – you can toggle this check box depending on whether or not you have headers in your data. I’m going to leave it checked for the purpose of this example. The check box “Column” is the name of the column I’m removing duplicates from, if multiple columns are selected in the first step – they can be managed from here.

Once you’re ready, click OK, and the below message will appear – giving you a few details about what has occurred:

Remove Duplicates Message Box

The result:

Remove Duplicates Result

                          

Ouput is a “simplified” version of Output Into. Output will simply print the results to screen, where as Output Into will insert the results into a specified table.

These keywords have access to two sytem tables, inserted and deleted. The inserted table contains all data that is added, anything inserted into a table with an insert statement, or the new data added within an update statement. The deleted table holds the opposite, anything removed with a delete statement, or anything overwritten with an update statement.

The below examples show how to use the Output clause with a Delete, Insert, and Update Statement.

DELETE FROM Person
OUTPUT deleted.PersonId, deleted.Name INTO PersonAudit
WHERE PersonId = 73

INSERT INTO Person
OUTPUT inserted.PersonId inserted.Name INTO PersonAudit
VALUES('Zach Stagers')

UPDATE Person
SET Name = 'Zach Stagers'
OUTPUT inserted.PersonId, inserted.Name, deleted.Name INTO PersonAudit
WHERE PersonId = 88

With each of the above examples, remove INTO PersonAudit to use the simplified version mentioned earlier, and just print the results to screen.

With a little bit of planning and correct use of the Output Into clause, you have the ability to create a very useful audit trail.

                          

ALTER SCHEMA MySchema TRANSFER dbo.Sproc;

The above example will move the object “dbo.Sproc” into the “MySchema” schema.

Short and sweet.