Now that I've discussed converting XML into a set of HIERARCHYID values I thought I'd try to reverse the process...

Not sure if you’ve attempted to convert a table with HIERARCHYID to an XML representation, and if you have, I’m sure you’ve experienced the same woes as me. Sure, I could have taken the route of using C# to create the XML, and it very well may be a better way to make such a conversion; instead I decided that I had to be able to do this in T-SQL, and so began the journey to find such a solution...

Since the XML modify method can only insert into a single node in an XML document, I had to either attempt to generate a string representation of the xml form the data (no simple task) or I could cursor through the data one row at a time (yes, cursor) and insert each node. For this implementation, I choose the cursor method simply because it would be easier to do than to recreate the XML document abilities akin to what is done in the .NET framework.

When using XQuery to insert nodes, you must use a static value (in other words, you cannot use a composed string variable for the XQuery in the XML modify method). At first, this made it difficult to figure out how to insert a node into another node since there was no point of reference.

And so thought that I could use the HIERARCHID’s ToString() method to figure out node positions in the XML, but that quickly was discarded after realizing that the path representation is guaranteed to be neither consecutive nor integers, and it would require using sp_executesql, which I also wanted to avoid.

Then I thought that the data would probably be uniquely identifiable, and so I could use that “id” to add an attribute to every node that I constructed and then cursor through and insert into the node that matched the parent id of the node I was inserting, which removed the need to use sp_executesql. In other words, I would create a cursor that contained the parent node ID and concatenated values from the row of data to create the node with an “id” attribute.


SET @XR.modify('insert sql:variable("@xcol") into (//*[@id=sql:variable("@hparentid")])[1]')

This uses the sql:variable extension to find a node via a relative reference. It looks for the node, regardless of location in the XML, with the attribute" “id” equal to the “id” of the parent which is contained in the @hparent variable.

Alas, this could become more problematic if the unique key contained multiple fields. One also might not want to include an extra “id” attribute in the results. Because of these and other things that I realized could go wrong with this implementation, I decided to scrap it and moved on. And although the version I am about to present has its own potential for issues, I felt it was more flexible and cleaner in its approach. Essentially what I decided to do is to use a temp table that contained the generated the XML node, the original HIERARCHYID value, a row number, generated with ROW_NUMBER() ordered by the hierarchy order, and a parent row number, which would initially set to 0 then updated using a self join on the temp table.

Then since the XML nodes position will match the generated row number based on the HIERARCHYID position, we can simply insert the new node into the parent node based on its position.

-- Sample Data to test with
CREATE TABLE #HTable (NodeName sysname, Attributes xml, NodeText VARCHAR(MAX), HierarchyNode HIERARCHYID)
INSERT INTO #HTable (NodeName, Attributes, NodeText, HierarchyNode)
VALUES 
   ('a', '<a attr="1" />', NULL, 0x),
   ('b', NULL, NULL, 0x58),
   ('c', '<a xyz="3" />', 'abc', 0x5AC0),
   ('c', NULL, 'def', 0x5B40),
   ('b', '<a id="111" pid="1234" />', NULL, 0x68),
   ('c', NULL, 'abc', 0x6AC0),
   ('c', NULL, 'def', 0x6B40)


CREATE TABLE #T (XmlToInsert XML, HierarchyNode HIERARCHYID, RowNum INT, ParentRowNum INT)

-- INSERT the generated XML node, the original HIERARCHYID, a unique row number, and a parent row number (set to 0)
INSERT INTO #T (XmlToInsert, HierarchyNode, RowNum, ParentRowNum) 
SELECT 
   CAST(
           '<' + NodeName + ' '
           + CASE WHEN Attributes IS NOT NULL 
               THEN SUBSTRING(CAST(Attributes AS VARCHAR(MAX)), 3, LEN(CAST(Attributes AS VARCHAR(MAX))) - 4)
               ELSE '' END
           + '>' + ISNULL(NodeText, '') + '</' + NodeName + '>'
       AS XML) AS XmlToInsert
   , HierarchyNode 
   , ROW_NUMBER() OVER (ORDER BY HierarchyNode) AS RowNum
   , 0 AS ParentRowNum
FROM #HTable
ORDER BY HierarchyNode

-- UPDATE the parent row number using the HIERARCHYID method GetAncestor in the self join
-- If the amount of data is great, an index could be created on the temp table prior to the update
UPDATE T1
SET T1.ParentRowNum = T2.RowNum
FROM #T AS T1
   INNER JOIN #T AS T2 ON T2.HierarchyNode = T1.HierarchyNode.GetAncestor(1)

DECLARE @xcol XML, @parentrownum INT, @flag BIT = 0, @XR XML = ''

-- We actually only need the generated XML and the parent row number to do the rest of this work
DECLARE crH CURSOR READ_ONLY FOR SELECT XmlToInsert, ParentRowNum FROM #T ORDER BY RowNum
   
OPEN crH

FETCH NEXT FROM crH INTO @xcol, @parentrownum
WHILE(@@FETCH_STATUS = 0)
BEGIN
       -- First time through, we add a root node
       IF @flag = 0
           SET @XR.modify('insert sql:variable("@xcol") into (/)[1]')
       ELSE -- Subsequent passes we find the parent node by position
           SET @XR.modify('insert sql:variable("@xcol") into (//*)[sql:variable("@parentrownum")][1]')
       
       SET @flag = 1
       FETCH NEXT FROM crH INTO @xcol, @parentrownum
END
CLOSE crH
DEALLOCATE crH
DROP TABLE #T
DROP TABLE #HTable
SELECT @xr


I did try one other version that used a recursive CTE to generate the list of nodes and their respective “rownum” and “parentRowNum”:


;WITH H1 AS
(  SELECT  
      NodeName
      , Attributes
      , NodeText
      , HierarchyNode  
      , ROW_NUMBER() OVER (ORDER BY HierarchyNode) AS RowNum 
   FROM #HTable AS HT
)
, H 
AS
(  SELECT  
      CAST( 
              '<' + NodeName + ' ' 
              + CASE WHEN Attributes IS NOT NULL  
                  THEN SUBSTRING(CAST(Attributes AS VARCHAR(MAX)), 3, LEN(CAST(Attributes AS VARCHAR(MAX))) - 4) 
                  ELSE '' END 
              + '>' + ISNULL(NodeText, '') + '</' + NodeName + '>' 
          AS XML) AS XmlToInsert 
      , HierarchyNode  
      , RowNum
      , CAST(0 AS BIGINT) AS ParentRowNum 
   FROM H1 AS HT
   WHERE HierarchyNode = HIERARCHYID::GetRoot()
   
   UNION ALL
   
   SELECT  
      CAST( 
              '<' + HT.NodeName + ' ' 
              + CASE WHEN HT.Attributes IS NOT NULL  
                  THEN SUBSTRING(CAST(HT.Attributes AS VARCHAR(MAX)), 3, LEN(CAST(HT.Attributes AS VARCHAR(MAX))) - 4) 
                  ELSE '' END 
              + '>' + ISNULL(HT.NodeText, '') + '</' + HT.NodeName + '>' 
          AS XML)
      , HT.HierarchyNode  
      , HT.RowNum
      , H.RowNum 
   FROM H1 AS HT
       INNER JOIN H ON H.HierarchyNode = HT.HierarchyNode.GetAncestor(1) 
)
INSERT INTO #T (XmlToInsert, HierarchyNode, RowNum, ParentRowNum)  
SELECT XmlToInsert, HierarchyNode, RowNum, ParentRowNum
FROM H
ORDER BY HierarchyNode


Instead of inserting the initial values into the temp table #T, this generates the completed set of data and then inserts it into #T. However, regardless of what variation I tried (e.g. add indexes), the initial method I show that inserts then updates #T was always faster.

Please let me know if you have any ideas that might optimize this, and if you have an implementation (T-SQL or .NET), please share.

A friend and colleague of mine, Caleb Jenkins, has started a fitness challenge (http://calebjenkins.wordpress.com/2009/01/29/official-rules/) and I decided that it was time for me to accelerate my fitness program that I had started in January. As of 9:00 AM on February 1, I weighed in at 201 pounds. My overall and ambitious goal is to lose at least 20 pounds. I hope to lose at least 10 pounds during the month of February. Even if I don’t win the fitness challenge, I will be much better off and will hopefully get to my ultimate goal of staying under 180 pounds.

I worked out on Saturday and Sunday. On Sunday I also helped my 5 year old son attempt to ride his bicycle without training wheels for the first time. My backs hurts from leaning over and catching Chris from falling. I am sore. I am achy. But I am determined. Wish me luck on my road to a healthier lifestyle.

It took a while, but a new e-book authored by yours truly, Greg Low, and Mark Whitehorn is finally available. And it's free!

To get your free copy, browse to http://www.microsoft.com/learning/sql/2008/default.mspx. From there, look in the Special Offers section for the "Free e-book offer". Although the site states you can get excerpts, the whole book is available for reading.

Many, many thanks to Greg and Mark for their quality contributions to the book.

Dan Jones wrote a great post about Facets from the new Policy-Based Management feature of SQL Server 2008. At one point in the post, he listed all of the available facets and their supported evaluation modes. Since SQL Server 2008 is not RTM, and since facets can be added in the future, I thought I'd write a query that would list the facets and supported evaluation modes.

Note that the On Demand mode is always supported and has therefore been left out of the query.

;WITH EM (EvalModeID, EvalModeName)
AS
(  SELECT *
   FROM
       (VALUES 
           (1, 'Check on Change: Prevent'),
           (2, 'Check on Change: Log'),
           (4, 'Check on Schedule')) AS EvalModes (EvalModeID, EvalModeName)
)
, FEM (FacetID, FacetName, EvaluationMode, IsSupported)
AS
(  SELECT
       pmf.management_facet_id
       , pmf.name
       , EM.EvalModeName
       , 1 
   FROM msdb.dbo.syspolicy_management_facets AS pmf
       INNER JOIN EM ON pmf.execution_mode & EM.EvalModeID = EM.EvalModeID
)
SELECT FacetID
   , FacetName
   , [Check on Change: Prevent]
   , [Check on Change: Log]
   , [Check on Schedule]
FROM FEM
PIVOT 
(  COUNT(IsSupported)
   FOR EvaluationMode IN ([Check on Change: Prevent], [Check on Change: Log], [Check on Schedule])
)AS FEMP
ORDER BY FacetName

The results for the existing 72 facets are as follows:

After numerous questions and requests, we decided to create a forum for all SQL Server related questions. You can view the new forum at http://sqlblog.com/forums/57/ShowForum.aspx or use the Forums menu item on the site to browse there. We hope this new addition to the SQLblog community provides the members a valuable benefit and look forward to seeing your forum posts.

Earlier today, Will Sullivan posted a blog entry, My Statement on Stored Procedures, in which he emphatically states his official opinion of stored procedures as:

"I prefer not to use them."

He then goes about dismissing most of the misinformation about why stored procedures are better than ad-hoc (parameterized) queries.

The first bit of misinformation he dispels is the now defunct argument that "Stored Procedures are faster than ad-hoc queries". He states that "Unless your ad-hoc queries are always significantly different from each other, their execution plans are cached right along side those of the SP's." I completely agree. We'll call that one a tie, so the score so far: SP 0, Ad-hoc 0.

Another myth he tries to debunk is that "Editing SP's is a breeze with Query Analyzer". Query Analyzer - that's so SQL Server 2000. Seriously, though, there are a number of fine code editors that allow you to edit SPs with ease. Query Analyzer is not at the top of that list, however. I will say that when you write T-SQL you should use a code editor that is meant for T-SQL, for the same reasons that when you write C#, you want to use a code editor meant for C#. Again, no winner here, so the score remains: SP 0, Ad-hoc 0.

He addresses another statement that is supposedly made in defense of SPs: "Ad-hoc queries are a nightmare to maintain, as they are spread all over your code". Again, either one is easy to maintain, with the right tools. We are still scoreless: SP 0, Ad-hoc 0.

It just so happens that I agree with many of his points. And there are other objective and subjective points on topics such as organization, maintenance, design, and so on, which one could argue for either SPs or ad-hoc queries equally so. Don't get me wrong, however, as I believe that using ad-hoc queries when you could have used stored procedures is simply wrong.

And so I will address Will's last point (actually, it was his second point) that is repeatedly misrepresented: "Stored Procedures are safe against SQL injection attacks; ad-hoc queries are not".

Ad-hoc queries prevent SQL Injection attacks as well as SPs do. Any claim otherwise would be wrong. But that's not the issue. The problem is that ad-hoc queries require that you expose the underlying objects of the database. In order to use ad-hoc queries, you must allow direct access for select, insert, update, and delete operations to the tables in the database. Although I know most experienced developers would only write ad-hoc/parameterized queries against the underlying data, at a later date, some disgruntled or inexperienced developer may write dynamic SQL instead (I have seen it happen), and expose the database to SQL injection attacks (which I have also seen in production systems), including exposure to such awful actions as...

-- Can you say Identity Theft?
SELECT FirstName, LastName, ZIP, CreditCardNumber, CreditCardType, CreditCardExpoiration, CVV 
FROM Customers

...or worse...

-- Do we really need all those customers?
DELETE Customers

...or even worse...

-- NEVER EVER DO THIS, PLEASE
-- This will execute a DELETE against all tables
EXEC sp_MSforeachtable 'DELETE ?'

...or even, even worse (assuming the SQL login has elevated permissions - which many apps do)...

-- NEVER EVER DO THIS, PLEASE
-- This will drop all tables from the database
EXEC sp_MSforeachtable 'DROP TABLE ?'

...and so although your ad-hoc query code won't allow SQL injection, some other programmer's dynamic SQL will. Assuming you've correctly secured your database, this doesn't happen with stored procedures since you do not have to expose any of the underlying tables (because of a little something known as chain of ownership).

Of course, you could completely self-destruct any security benefits by creating a SP such as this one:

-- NEVER EVER DO THIS, PLEASE, I beg of you...
CREATE PROC prExecuteSql (@sql VARCHAR(MAX))
WITH EXECUTE AS dbo
AS
    EXEC (@sql)
GO

As you can see, SPs aren't fool proof, but you can mitigate your risk by having an employee or a consultant who knows what they are doing in the database.

Yes, there are some applications will not require the extra security, or other factors may simply prevent you from using stored procedures, and so using ad-hoc SQL is a viable option in those cases. But I believe that security should be at the top of your important-things-for-your-application list, and alas, ad-hoc queries require you to unnecessarily expose your database objects, which will more than likely lead to problems down the road.  You can argue any other point and there are no clear winners, but when it comes to security, ad-hoc loses. If you want to a more secure database, you need to be using SPs.

And so, the final score (well, for now anyways): SP 1, Ad-hoc 0.

Bloggers at SQLblog.com were occasionally having issues posting. We had narrowed down the cause to the use of bracketed identifiers with certain text, such as [name] or [date], so that when a post contained a query such as this: