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

Chapter 16: A Brief XML Primer
512
❑ MetaProperties are a set of special variables that you can refer to in your OPENXML queries. They
describe various aspects of whatever part of the XML DOM you’re interested in. To use them,
just enclose them in single quotes and put them in the place of the column XPath. Available
MetaProperties include:
❑ @mp:id: Don’t confuse this with the XML id that we looked at with EXPLICIT. While
this property serves a similar function, it is a unique identifier (within the scope of the
document) of the DOM node. The difference is that this value is system generated — as
such, you can be sure it is there. It is guaranteed to refer to the same XML node as long
as the document remains in memory. If the id is zero, it is the root node (its
@mp:parentid property, as referred to below, will be NULL).
❑ @mp:parentid: This is the same as above, only for the parent.
❑ @mp:localname: Provides the non-fully qualified name of the node. It is used with prefix
and namespace URI (Uniform Resource Identifier — you’ll usually see it starting
with URN) to name element or attribute nodes.
❑ @mp:parentlocalname: This is the same as above, only for the parent.
❑ @mp:namespaceuri: Provides the namespace URI of the current element. If the value of
this attribute is NULL, no namespace is present.
❑ @mp:parentnamespaceuri: This is the same as above, only for the parent.
❑ @mp:prefix: Stores the namespace prefix of the current element name.
❑ @mp:prev: Stores the mp:id of the previous sibling relative to a node. Using this, you can tell
something about the ordering of the elements at the current level of the hierarchy. For example,
if the value of @mp:prev is NULL, then you are at the first node for this level of the tree.
❑ @mp:xmltext: This MetaProperty is used for processing purposes, and contains the
actual XML for the current element.
Of course, you can always save yourself a ton of work by bypassing all these parameters. You get to do
this if you have a table that directly relates (names and data types) to the XPath starting point that
you’ve specified in your XML. If you do have such a table, you can just name it and SQL Server will
make the translation for you!
OK, that’s a lot to handle, but we’re not quite finished yet. You see, when you’re all done with your
XML, you need to call sp_xml_removedocument to clean up the memory where your XML document
was stored. Thankfully, the syntax is incredibly easy:
sp_xml_removedocument [hdoc = ]
I can’t stress enough how important it is to get in the habit of always cleaning up after yourself. I know that,
in saying that, I probably sound like your mother. Well, like your mother, SQL Server will clean up after you
some, but, like your mother, SQL Server won’t clean up after you every time. SQL Server will clean things
up when you terminate the connection, but what if you are using connection pooling? Some connections may
never go away if your system is under load. It’s an easy sproc to implement, so do it — every time!
OK, I’m sure you’ve been bored waiting for me to get to how you really make use of this — so now it’s
time for the all-important example.