17.06.2013 Views

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

While EXPLICIT has not been deprecated as yet, make no mistake — PATH is really meant to be a better<br />

way of doing what EXPLICIT originally was the only way of doing. PATH makes a lot of sense in a lot of<br />

ways, and it is how I recommend that you do complex XML output in most cases.<br />

This is a more complex recommendation than it might seem. The <strong>Microsoft</strong> party line on this is that<br />

PATH is easier. Well, PATH is easier is many ways, but, as we’re going to see, it has its own set of<br />

“Except for this, and except for that, and except for this other thing” that can twist your brain into<br />

knots trying to understand exactly what to do. In short, in some cases, EXPLICIT is actually easier if<br />

you don’t know XPath. The thing is, if you’re dealing with XML, then XPath should be on your learn<br />

list anyway, so, if you’re going to know it, you should find the XPath-based approach more usable.<br />

Note, however, that if you’re needing backward compatibility to <strong>SQL</strong> <strong>Server</strong> 2000, then you’re going to<br />

need to stick with EXPLICIT.<br />

In its most straightforward sense, the PATH option isn’t that bad at all. So, let’s start by getting our feet<br />

wet by focusing in on just the basics of using PATH. From there, we’ll get a bit more complex and show<br />

off some of what PATH has to offer.<br />

PATH 101<br />

With PATH, you have a model that molds an existing standard to get at your data — XPath. XPath has an<br />

accepted standard, and provides a way of pointing at specific points in your XML schema. For PATH,<br />

we’re just utilizing a lot of the same rules and ideas in order to say how data should be treated in a<br />

native XML sort of way.<br />

How PATH treats the data you refer to depends on a number of rules including whether the column is<br />

named or unnamed (like EXPLICIT, the alias is the name if you use an alias). If the column does have a<br />

name, then a number of additional rules are applied as appropriate.<br />

Let’s look at some of the possibilities.<br />

XPath is its own thing, and there are entire books dedicated to just that topic. PATH utilizes a wide variety<br />

of what’s available in XPath, and so there really is too much to cover here for a single chapter in a<br />

beginning text. That said, we’re going to touch on the basics here, and give you a taste of the more<br />

advanced stuff in the next section. From there, it’s really up to you whether you want to learn XPath<br />

more fully, and from there, what pieces of it are understood by PATH. More advanced coverage of this is<br />

also supplied in the next book in this series: Professional <strong>SQL</strong> <strong>Server</strong> <strong>2008</strong> Programming.<br />

Unnamed Columns<br />

Data from a column that is not named will be treated as raw text within the row’s element. To demonstrate<br />

this, let’s take a somewhat modified version of the example we used for XML RAW. What we’re<br />

doing here is listing the two customers we’re interested in and the number of orders they have placed:<br />

SELECT CustomerID, COUNT(*)<br />

FROM Sales.SalesOrderHeader Orders<br />

WHERE CustomerID = 29890 OR CustomerID = 30067<br />

GROUP BY CustomerID<br />

FOR XML PATH;<br />

Chapter 16: A Brief XML Primer<br />

505

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!