If you want to parse an XML document with the XmlReader, it might help to use this XmlReader example from MSDN. However, there's one thing missing: If you parse an XML with empty elements, such as:
<example1 />
<example2>bla</example2>
the example doesn't set the closing tags write, but like this:
<example1>
<example2>bla</example2>
</example1>
In order to omit this problem, you have to write the end elements in case that the reader parses an empty element:
case XmlNodeType.Element:
writer.WriteStartElement(reader.Name);
writer.WriteAttributes(reader, true);
if (reader.IsEmptyElement)
writer.WriteEndElement();
break;
Random pitfalls (and their solutions) in EAI technologies such as BizTalk
Showing posts with label XML. Show all posts
Showing posts with label XML. Show all posts
Tuesday, September 27, 2011
Sunday, January 25, 2009
Managing hierarchical data in SQL Server 2008
There are roughly three different approaches to store and retrieve hierarchical data in SQL Server:
Parent-Child-Approach with Recursive TCE:
You can save the ID of a node's parent in an extra “parent column”:

Then you connect the referenced items with recursive Common Table Expressions (CTE).
HierarchyID data type:
Or you save the node’s hierarchy location with the new data type HierarchyID, which stores a path to a node and, thus, reveals the where in a tree the row occurs. A sample table looks like this:

The hierarchy is directly visible and, unlike in the simple parent-child-pattern, you have now the HierarchyID methods to work against the tree structure.
XML data type:
The third option is to represent the hierarchy in a XML document and store the instance in an xml column:

Doing this, you can retrieve information from the tree using XQuery.
This is meant to be a teaser... ;-) I'm going to write more about this the next days.
Parent-Child-Approach with Recursive TCE:
You can save the ID of a node's parent in an extra “parent column”:

Then you connect the referenced items with recursive Common Table Expressions (CTE).
HierarchyID data type:
Or you save the node’s hierarchy location with the new data type HierarchyID, which stores a path to a node and, thus, reveals the where in a tree the row occurs. A sample table looks like this:

The hierarchy is directly visible and, unlike in the simple parent-child-pattern, you have now the HierarchyID methods to work against the tree structure.
XML data type:
The third option is to represent the hierarchy in a XML document and store the instance in an xml column:

Doing this, you can retrieve information from the tree using XQuery.
This is meant to be a teaser... ;-) I'm going to write more about this the next days.
Subscribe to:
Posts (Atom)