Author Topic: Retrieving Data as XML from SQL Server  (Read 15257 times)

Offline admin

  • Administrator
  • Sr. Member
  • *****
  • Posts: 296
    • View Profile
Retrieving Data as XML from SQL Server
« on: July 03, 2008, 07:22:26 AM »
Retrieving Data as XML from SQL Server
By Mitchell Harper

All the hype that once surrounded XML is finally starting to die down, and developers are really beginning to harness the power and flexibility of the language. XML is a data descriptive language that uses a set of user-defined tags to describe data in a hierarchically-structured format.

The release of Microsoft SQL Server 2000 a couple of months ago saw Microsoft jump on the XML band-wagon too - they've included a number of different ways to manipulate data as well-formed XML. Firstly, there's the SQL XML support. Microsoft's implementation of SQL XML provides a simple configuration tools that allows developers to gain remote access to databases using URL based queries over HTTP. For example, we can setup an SQL XML virtual directory on our Web server named "myVirtual". Then, assuming we have the appropriate security permissions, we can use any browser to query our database using a simple URL based query (such as: http://www.myserver.com/myVirtual?SQL=select+*+from+products+for+xml+auto). This then returns our results as an XML based recordset.

Notice the "for xml auto" part of our query above? This determines the way in which SQL Server 2000 shapes our data. There are three shaping methods:


"for xml auto": Returns XML elements that are nested, based on which tables are listed in the "from" part of the query, and which fields are listed in the "select" part.


"for xml raw": Returns XML elements with the "row" prefix (ex: "<row tProduct …>"). Each column in a table is represented as an attribute and null column values aren't included.


"for xml explicit": Explicit mode is the most complex shaping method used in SQL Server 2000. It allows users to query a data source in such a way that the names and values of the returned XML are specified before the query batch is executed.

It's this third method, "for xml explicit", that I will discuss today. The explicit method, in my opinion, is the most powerful feature of SQL Server 2000. Not only can we specify how our XML data is returned to us, but we can also use record filters and sorting patterns as well, because, as we all know, sorting an XML document any other way is almost impossible.

Now, let's get into it. This article is aimed at the intermediate to advanced developer who's looking to use XML in the BLL (business logic layer) of an n-Tier based application where speed is a critical issue. To benefit from this article, you'll need to equip yourself with the following:


A Win2k box running IIS and SQL Server 2000 with XML support
Basic ASP, SQL, XML and XSL knowledge


Step 1: Creating our sample database
On your SQL Server 2000 server, open Enterprise Manager and create a new database named "myProducts". Then, using either Enterprise Manager, or Query Analyser, create the tables shown below:



(Note: catId, productId and descId are all auto-incrementing identity fields)

As you've probably guessed, we're using three tables to simulate a very simple product description database (let's assume we sell books). The diagram above shows the hierarchy of our data: categories listing products, listing their descriptions. Before we progress to the next step, we'll need to create some dummy data in our tables. To maximise productivity and minimise the length of this article, I've created a simple T-SQL script, that will populate our tables as needed, you can download it here. The script will create 3 categories, 7 products and 7 descriptions.

Offline admin

  • Administrator
  • Sr. Member
  • *****
  • Posts: 296
    • View Profile
Re: Retrieving Data as XML from SQL Server
« Reply #1 on: July 03, 2008, 07:24:42 AM »
Step 2: Creating the stored procedure
To retrieve our data in an XML format, we will compress our query batch into a single stored procedure. This encourages code reuse strategies and is easily modifiable in the future. Lets start by loading up query analyser on our database server (Start -> Programs -> Microsoft SQL Server -> Query Analyser).

When prompted, enter your database login credentials. You should be connected to the server on which you created the myProducts database. Next, enter the following T-SQL which I will explain shortly:

use myProducts
go
CREATE PROCEDURE sp_GetExplicitXML
AS
 SELECT 1 AS Tag,
   NULL AS Parent,
   c.catName as [Category!1!CatName],
   NULL as [Product!2!ProdName],
   NULL as [Product!2!Description]
 FROM categories c
UNION ALL
 SELECT 2 AS Tag,
   1 AS Parent,
   c.catName,
   p.productName,
   d.descText
 FROM categories c, products p, descriptions d
 WHERE c.catId = p.productCat AND p.productId = d.descProdId
 ORDER BY [Category!1!CatName], [Product!2!ProdName]
 FOR XML EXPLICIT

Don't get scared away by the code for the stored procedure above, I promise, it's easy! Allow me to explain the code step by step.

use myProducts
go
CREATE PROCEDURE sp_GetExplicitXML
AS

If you've ever worked with T-SQL then you should be familiar with these commands. The "use myProducts" command tells SQL Server to "run any queries that we execute against the myProducts database". The "go" command tells SQL server to execute all the code that resides above that line right now. Next, we tell SQL server that we will create a new stored procedure named sp_GetExplicitXML. The stored procedure will accept no input parameters and will not return any output values.


 SELECT 1 AS Tag,
   NULL AS Parent,
   c.catName as [Category!1!CatName],
   NULL as [Product!2!ProdName],
   NULL as [Product!2!Description]
 FROM categories c
UNION ALL
 SELECT 2 AS Tag,
   1 AS Parent,
   c.catName,
   p.productName,
   d.descText
 FROM categories c, products p, descriptions d

This is the main chunk of code for our stored procedure. Remember how I said earlier, that when using the "FOR XML EXPLICIT" mode, you can control the shape, column names and content of the returned XML? Well, this is the code that does that for us. The code above acts as a template into which a universal table will be created. A universal table is similar to a normally mapped SQL table with just a couple of differences:


A universal table mimics a hierarchical structure by using "tag" and "parent" fields to measure the depth of the data hierarchy. You'll notice in our code above, that the first select command has a tag of 1 with no parent. In the next select statement, there is a tag of 2, with a parent of 1, which means that all the results returned from the second select statement will be children of the first select statement.
As you've probably noticed, the column names for a universal table differ from normal column names. Lets break down the name of one of our universal table column names from the code above:
[Category!1!CatName] As you can see, the column name has three values separated by an exclamation mark. The first value is the name of the XML element that the universal table will produce. The second is the tag index, which lets SQL's internal XML pointer know which level of the hierarchy into which this data will be placed. The last value, "CatName" is the name of the attribute into which the value of the select statement will be inserted. A sample category element from our database would look like this: <Category CatName="ASP">

Notice how there are two NULL values in the first select statement? That's because in the first statement, we're only concerned with the categories for our books, which come from the categories table ("FROM categories c"). These values are left NULL because they'll be filled in in the next select statement (where we deal with the categories, products and descriptions tables). If this all sounds a little confusing, take a look at the diagram below:



Now, to the last part of the code.

 WHERE c.catId = p.productCat AND p.productId = d.descProdId
 ORDER BY [Category!1!CatName], [Product!2!ProdName]
 FOR XML EXPLICIT

In this final chunk of our code, we make sure that each category displays only the products whose productCat field is equal to their catId field. Also, we match each product with its description using the "p.productId = d.descProdId" test. Lastly, we sort the XML output by ascending category name, and ascending product name (NB: Remember to run the code by pressing Alt+X).

Offline admin

  • Administrator
  • Sr. Member
  • *****
  • Posts: 296
    • View Profile
Re: Retrieving Data as XML from SQL Server
« Reply #2 on: July 03, 2008, 07:27:10 AM »
Displaying the Results:
Now that we've created our stored procedure named sp_GetExplicitXML, we'll want to be able to do something useful with it. We can start by making sure the stored procedure returns the results we expected by typing the following code into a new query analyser window:

use myProducts
go
exec sp_GetExplicitXML

If all goes well, you'll be presented with one row of XML that contains the results of the stored procedure. To display our results in a browser, we'll create an ASP script that will execute the stored procedure, load the results into an MSXML DomDocument object, and then transform the results using an XSL stylesheet. Create a new ASP script and call it prodtest.asp. Enter the following code into prodtest.asp and save it:

<!-- METADATA Type="TypeLib" File="c:\program files\common
files\system\ado\msado15.dll" -->
<%
dim objStream
dim objConn
dim objComm
dim objXML
set objStream = Server.CreateObject("ADODB.Stream")
set objConn = Server.CreateObject("ADODB.Connection")
set objComm = Server.CreateObject("ADODB.Command")
set objXML = Server.CreateObject("MSXML2.DOMDocument")
objConn.Open "Provider=SQLOLEDB; Data Source=(local); Initial 
Catalog=myProducts; UId=sa; Pwd="
objComm.ActiveConnection = objConn
objComm.CommandType = adCmdStoredProc
objComm.CommandText = "sp_GetExplicitXML"
objStream.Open
objComm.Properties("Output Stream").Value = objStream
objComm.Execute ,, adExecuteStream
objStream.Position = 0
objXML.LoadXML("<?xml version='1.0'?><?xml-stylesheet type='text/xsl' 
href='prodtest.xsl'?><My_Products>" &
objStream.ReadText & "</My_Products>")
if objXML.parseError.errorCode <> 0 then
 Response.Write "Error loading XML: " & objXML.parseError.reason
 Response.End
end if
Response.ContentType = "text/xml"
Response.Write objXML.xml
%>

I won't go into too much detail about the code for our prodtest.asp page. Put simply, we're using ADO command and stream objects to execute our stored procedure and read the results to an MSXML DOMDocument which is then parsed and checked for errors. If there are no errors, we change the content-type of our output to text/xml and write the XML to the browser.

Notice that a stylesheet is set in our XML document to render the results into an easily readable format. The stylesheet, prodtest.xsl is shown below:

<?xml version="1.0" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<xsl:template match="/">
<html>
<head>
<title> Sample Products </title>
</head>
<body>
<h1>Books in Catalog</h1>
<table border="0" cellspacing="2" cellpadding="3">
<xsl:for-each select="My_Products/Category">
<tr>
<td width="100%" bgcolor="#C0FFC0">
<xsl:value-of select="@CatName"/>
</td>
</tr>
<xsl:for-each select="Product">
<tr>
<td width="100%" bgcolor="#E9E9E9">
 <p style="margin-left:30"><xsl:value-of select="@ProdName"/></p>
</td>
</tr>
</xsl:for-each>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>

Once we've saved the stylesheet in the same directory as our prodtest.asp file, we can fire up our browser and run prodtest.asp (make sure you save the files into a directory that can be processed by IIS). There results are shown below:



Conclusion:
Microsoft have successfully implemented XML support into their overall Web strategy, and this is blatantly obvious in SQL Server 2000. If some of the code above was a bit hard to understand, persevere. It took me almost two weeks to learn when I first started!

The stored procedure we created is just one of the many ways to incorporate XML into the business logic layer of any n-Tier application, keeping in mind that many, if not all of the world's top development companies have already incorporated/are planning to incorporate XML support into their products now or in the future.