This means that I am now a “Technology Specialist in SQL Server Developement (2008)” and a “Microsoft Certified IT Professional in Database Development (2008)”.

The 70-451 exam was pretty different to the 70-433. The questions were more focused on database design and data access, rather than remembering syntax.

The exam is also a little trickier to study for, as there aren’t any Microsoft Publications based around it. I would recommend getting hold of some practice test (I used Transcenders), studying them hard, and googling any terms you haven’t come across before or don’t feel you know well enough.

Next I plan on taking a break from certifications, and broadening my horizons by learning some C#! Wish me luck…

I’ve been meaning to take one of these exams for a long time now, and I’ve finally managed to do it. I spent a lot of time reading and practicing, and I’m glad that it’s all payed off!

A big thank you to a man named Niall Merrigan, as achieving this without his blog and 70-433 study guide would have been a lot more difficult! I recomend you check his site out if you’re going to take this exam.

Another resources I used was the MCTS Self-Paced Training Kit (Exam 70-433): Microsoft SQL Server 2008 – Database Development Book/DVD Package:

The informartion in this book was good, and gave a very good understanding of most things covered in the exam. I found the practice tests to be fairly similar to the real deal, and gave decent examples and links to other resources (such as MSDN and Microsoft TechNet) when reviewing the answers. Overall – I would recommend using this book whilst studying for your 70-433 exam, but you will need to top your knowledge up with the links given in the answer reviews – and maybe a few visits to Niall’s blog mentioned above.

Many of my own blog posts are also focused on the topics covered in this exam, so be sure to check back here if you need a little help.

The next exam I’ll be tackling is the 70-451, this is the next exam in the series to achieve the certification of MCITP: Database Developer 2008. I’m sure that this will require much more reading. I’ll be sure to post back with more tips once I’ve finished this one too!

ALTER SCHEMA MySchema TRANSFER dbo.Sproc;

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

Short and sweet.

I’ll also be discusing nested XML Queries in this post, which kind of goes hand in hand with FOR XML PATH. More on this later.

I’ll start off with an example, then explain what’s going on afterwards:

SELECT P.Name AS "@Name",
       P.Age AS "@Age",
       'PersonId = ' + CAST(P.PersonId AS VARCHAR(5)) AS "comment()",
       (
        SELECT O.OrderId AS "@OrderId",
               O.Item AS "@Item"
	FROM Orders O
	WHERE O.PersonId = P.PersonId
	FOR XML PATH('Order'), TYPE
       ) 

FROM Person P

WHERE P.PersonId IN (1, 2)

FOR XML PATH('Person'), ROOT('People'), ELEMENTS XSINIL

As with each of the other XML Modes (Raw, Auto, and Explicit), you’re able to change the name of your elements from the default. To achieve this use FOR XML PATH('Person'), this will give your rows the name “Person”.

ROOT('People') specifies the root element to be wrapped around you’re XML. The keyword ELEMENTS in this instance doesn’t do a whole lot as the structure is placed into elements and attributes depending on the names given to the columns, but XSINIL cannot be specified without it. XSINIL is used to give you’re XML a namespace, as well as to handle NULL values.

The actual output of the query used aboved is as below:

<People xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Person Name="Zach Stagers" Age="22">
    <!--PersonId = 1-->
    <Order OrderId="1" Item="Bike" />
    <Order OrderId="2" Item="Laptop" />
    <Order OrderId="3" Item="Phone" />
    <Order OrderId="4" Item="Keyboard" />
    <Order OrderId="5" Item="Mouse" />
    <Order OrderId="10" Item="Pizza" />
  </Person>
  <Person Name="Libbie Coulson" Age="24">
    <!--PersonId = 2-->
  </Person>
</People>

The first two columns in the select are specified as “@Name” and “@Age”, this assigns them as attributes to the Person Element.

Specifying the column names as “comment()” makes the value a comment within the XML, note that this is case sensitive – “comment()” is not the same as “Comment()”.

One column name that I haven’t used in the example is “text()”, this sets the value as the text of the element, instead of an attribute.. for example, using this against P.Name turns the value into:

 <Person Age="22">Zach Stagers</Person> 

Nested XML Queries

Nested XML Queries are what gives the FOR XML PATH mode its structure. To do this, as in the example above, you would use a correlated subquery. Here, you link the subquery to the outer query on the PersonId – linking the person to their orders, and therefore listing the orders beneath the correct person.

The subqueries FOR XML statement must have TYPE specified. This translates the queries results into true XML, Microsoft did this for backwards compatibility reasons.

I actually found that reviewing the results as tabular data is what really helped me understand what the FOR XML EXPLICIT query is doing.

Below is the example code that I’m using:

SELECT
	1 AS Tag,
	NULL AS Parent,
	Name AS "Person!1!Name",
	PersonId AS "Person!1!PersonId",
	NULL AS "Orders!2!Item"
FROM Person

UNION ALL

SELECT
	2 AS Tag,
	1 AS Parent,
	NULL AS "Person!1!Name",
	PersonId AS "Person!1!PersonId",
	Item AS "Orders!2!Item"

FROM Orders

ORDER BY "Person!1!PersonId"

FOR XML EXPLICIT, ROOT('People')

The first thing to note with this query, is the two columns “tag” and “parent”. You must specify these columns in order to use FOR XML EXPLICIT. These columns specify the hierarchy of your results. The first query will have a “tag” of 1, and a NULL “parent”, as it is the first object declared. Each subsequent “tag” and “parent” will then go up by increments of 1.

Another thing to note, is the column names. The value listed before the first exclamation in the column name specifies the Element Name. The value listed before the second exclamation is the “tag” that it relates to. Then the attribute name is specified. ElementName!TagNumber!AttributeName.

Lastly, it’s the ORDER BY "Person!1!PersonId" that really gives the final result its correct structure.

The XML outputted by the query specified above is as follows:

<People>
  <Person Name="Zach Stagers" PersonId="1">
    <Orders Item="Bike" />
    <Orders Item="Laptop" />
    <Orders Item="Phone" />
    <Orders Item="Keyboard" />
    <Orders Item="Mouse" />
    <Orders Item="Pizza" />
  </Person>
  <Person Name="Libbie Coulson" PersonId="2" />
</People>

As with RAW and AUTO, the ROOT() simply specifies the name of the root element. This is optional.

Without the aforementioned ORDER BY clause, all of the orders for person “Zach” would appear under “Libbie” as she is last in the list, and the UNION ALL will just tack the results from the second query to the end of the result. Ordering by the key between the two tables ensures that the orders against PersonId 1 appear under the person with PersonId 1.

As I mentioned earlier in this post, what really helped me understand what was happening with FOR XML EXPLICIT was seeing the results in there tabular format. To do this, simply remove the FOR XMLline and re-run the code. In the below tabular example, I’ve removed FOR XML EXPLICIT, ROOT('People') from the query:

To do a BULK INSERT, simply upload your file to the server that holds the database you’re going to be inserting into. Put the file in a relatively simple location, unless you like typing long file paths! Alternatively, you can copy and paste the file path, of course.

Below is the example file I’ll be using, along with the structure of the table…

Below is the structure of the example table I’ll be using, along with the contents of the file which will be imported.

--Table

CREATE TABLE dbo.Orders
(
OrderId INT NOT NULL,
PersonId INT NOT NULL,
Item VARCHAR(50) NOT NULL
)

--Contents of Orders.txt

4, 1, Keyboard
5, 1, Mouse

Once your file is in place, you’re ready to roll.

BULK INSERT dbo.Orders
FROM 'C:\Orders.txt'
WITH
(
FIELDTERMINATOR = ','
ROWTERMINATOR = '\n'
)

Notice the WITH statment after specifying the file location. I have only used a couple of the options available to the BULK INSERT statement. I will explain these, but a for a full list of options – see the MSDN site on BULK INSERT.

The two options I’ve used in the example are the only two that you should need to insert some relatively simple data.

FIELDTERMINATOR is used to specify the character used to split your data into the columns they belong to, you need to have the columns in the correct order in the file so that they are mapped correctly. Obviously, you need to pick a character that isn’t going to appear in any of the columns.

ROWTERMINATOR is used to specify what denotes a new row. In my example, I’ve used \n, which is equal to an enviromental newline. This tells SQL that any time there is a new line in the Orders.txt file, that this should be treated as a seperate row from the line above.

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 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 using the below two queries to return tabular data would give you the same results, 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.

For example, if you were writing a stored procedure which was going to be used by a reporting system, and within the system, a user will have the ability to narrow down a search by choosing options from various drop down lists. Instead of writing many different stored procedures to handle each of the different drop down lists, you can do it all within one using optional parameters.

An “optional parameter” is a parameter which is set to NULL by default. The parameter must be set to NULL by default

CREATE PROCEDURE dbo.GetSearchResults

@Franchise	VARCHAR(20) = NULL
@Make		VARCHAR(20) = NULL
@Colour		VARCHAR(20) = NULL

AS

SELECT Franchise,
       Make,
       Colour

FROM Vehicles

WHERE (@Franchise IS NULL OR Franchise = @Franchise) AND
      (@Make IS NULL OR Make = @Make) AND
      (@Colour IS NULL OR Colour = @Colour)

In the above example, if a value isn’t passed in for one of the parameters, then the default of NULL is used. This means that the first condition in the OR is true because the variable is NULL, and execution continues on to the next line.

The above stored procedure can also be called in a few different ways:

1)

EXEC dbo.GetSearchResults

This method simply uses all of the default values for each parameter, and the query results aren’t filtered in the where clause at all

2)

EXEC dbo.GetSearchResults 'Volkswagen', 'Golf'

This execution method uses the values passed in and assigns them to the parameter in the same position that the parameter is declared. By that I mean, @Franchise is declared first in the procedure, so Volkswagen would be assigned to this variable as it’s passed in first. This method is a little dangerous, as if the value intended for @Colour is passed in first, no results will be returned.

3)

EXEC dbo.GetSearchResults @Franchise = 'Volkswagen', @Colour = 'Red'

This method is probably the safest of the bunch, as it explicitly defines the value to the parameter. Any parameters that aren’t defined in the EXEC use the default value set in the procedrue.

USE database
SELECT S.name + '.' + O.name [SchemaTable]

FROM sys.all_objects O JOIN
     sys.schemas S ON S.schema_id = O.schema_id

WHERE type = 'U' AND
      is_ms_shipped = 0 AND
      S.schema_id IN (5, 6, 7, 8, 9)

ORDER BY O.name

The reason I needed a list of tables and the schemas they belong to in this format was because I needed to add two columns to each of them.

I’m far to lazy to open up each of these tables (there were 50 in total) and add the two columns manually, so I used the above SQL, as well as some concatenation to write the query for me:

USE database
SELECT 'ALTER TABLE ' + S.name + '.' + O.name + ' ADD Child VARCHAR(100) NULL,
       GrandChild VARCHAR(100) NULL' [SQL]

FROM sys.all_objects O JOIN
     sys.schemas S ON S.schema_id = O.schema_id

WHERE type = 'U' AND
      is_ms_shipped = 0 AND
      S.schema_id IN (5, 6, 7, 8, 9)

ORDER BY O.name 

I was then able to copy the results into a new query window and execute, saving myself a lot of time.

To do this, simply specify your escape character, typically a value which you know won’t be returned in the result set, before the character you’re searching for.

For example, if a column containing someones tax band was created as a VarChar, instead of a TinyInt and users were inserting the % symbol along with the rate you might want to find and correct these records before updating the columns data type. To do something like this, you would use a query like the below:

SELECT FirstName,
       Surname,
       TaxBand

WHERE TaxBand LIKE '%=%%' ESCAPE '='

This query specifies = as our ESCAPE symbol, therefore the % symbol listed after it can be searched for.