Irwin Dolobowsky's Blog : Articles & Other Mentions

SqlXml / MDAC Clarification

irwando — Mon, 07 Feb 2005 21:26:00 GMT

Apparently there's been a bit of confusion out there lately about the list of deprecated technologies in the Data Access Road Map. Both Ken and Bryant blogged about it, and I just wanted to clarify a few things:

- This article specifically referrs to SqlXml in MDAC. That's the SqlXmlx.dll file that provides nifty things like Templates and Updategams through SqlOleDB directly. This is actually a fairly old (1.0+) version of our code.

- SqlXml will be removed from future versions of MDAC, as in MDAC > 2.X. SqlXml still provies its own OleDb provider that can be used with MDAC or SQLNCLI (in Sql Server 2005). We will remain in the 2.X line.

- Notification Services has a dependency on SqlXml, but on the stand-alone version that contains Bulkload. The MDAC plans should not affect this at all.

So, SqlXml will be hanging around for a while, have no fears. Hope that clarifies a few things.

Two New Articles - Bulkload in .Net and FOR XML in SQL Server 2005

irwando — Mon, 28 Jun 2004 20:45:00 GMT

There are a few new SqlXml-related articles up on MSDN.

First we have Amar Nalla's XML to SQL: Using SQLXML Bulkload in the .NET Framework which gives great examples on constructing annotated schemas and using Bulkload within .Net. Amar goes into great detail on how to feed Bulkload with a stream, a process that takes some work when going from .Net through managed interop to Bulkload. If you're using Bulkload within .Net check it out, its a great article and well worth your time to read.

A little bit older is Michael Rys's article What's New in FOR XML in Microsoft SQL Server 2005 which discusses enhancements to the FOR XML extensions to T-SQL offered by SQL Server. I've played with the new extensions a bit, not nearly as much as I should have, but am none the less very enthused about them. I think the new PATH syntax will go a long way toward helping people construct complex shapes from there relational table quicker and easier than they could be for with EXPLICIT.

Of course, this brings up the question, if we have this great new PATH mode for making complex XML shapes, why do we need mapping? Its a question I've been asked on more than a few occasions, so here are a few reasons why I still consider mapping a valuable investment:

Composability - Let's say you want to produce results that conform to the same XML schema from several queries. If you're using FOR XML, each time you have a new query, you have to make sure the output matches your target schema. However, with mapping, you define your output once, and can then query it in many ways, each time only re-writing the query. You can also then allow others to give you queries to execute and you're still guaranteed the same output format - not possible with FOR XML.

Updates - FOR XML is wonderful for producing XML from your relational data. But what about if you want to update that same data? Now you have to have a stored procedure to do the update and a FOR XML to retrieve the data, and you have to figure out how the data produced by the FOR XML statement maps back to the database. With mapping, we provide both query and update technologies, so you only have to think about one thing - the XML.

Multiple Databases - This actually relates back to Composability. You have a few different SQL databases, some 2000, some 2005, maybe with the same relational schemas, maybe not. With mapping, you can establish a mapping to each database and then query them using the same XPath queries each time, and let us handle generating the query for that particular database. If you're using FOR XML, you have to write a query for each of those databases and make sure they all resolve to the same schema.

This isn't to say I don't think FOR XML is useless or anything (though I'm obviously a bit biased toward mapping), quite the contrary. You will get much more control of the queries you're doing by using it. There is just simply more you can do by constructing the query yourself, things SQLXML does not support. You can store those queries inside stored procedures within the database, making your DBA much happier I'm sure. You can leverage your existing SQL knowledge without having to know about mapping and XPath as well.

So what am I saying here? Which one you use depends on what you consider most valuable. Do you need every last bit of performance and do you need to fine tune every query? Go with FOR XML. Can you give up some control of your queries in exchange for more composability or the ability to update? Mapping is the way to go. You can even mix the two together, don't be afraid! Query all you like with FOR XML, but when you get that 30 meg XML document, look to Bulkload to get it loaded into your database. Its ok, all of the pieces will play very nicely together, I guarantee.

New Article - Xml Support in Microsoft Sql Server 2005

irwando — Fri, 21 May 2004 22:30:00 GMT

There's a great new article up on MSDN giving an overview of the XML Support in Sql Server 2005:

XML Support in Microsoft SQL Server 2005

How do I know its great? Well, because I contributed of course! Just a little, I did the section on SqlXml. Shankar Pal and Mark Fussell did most of it. Check it out for a great overview though.

Off to San Deigo tomorrow to get in a little golf before Tech-Ed. Demos and slides are mostly done, hopefully everyone will enjoy my talk. I've ended up with 23 slides, but that also includes a nice bulkload demo and an objects out of the database demo using SqlXml. Hopefully that will be “Extreme” enough for everyone.

Developer.com on Managed SqlXml Classes

irwando — Fri, 07 May 2004 20:59:00 GMT

Someone recently forwarded me this article on Developer.com about the SqlXml Managed Classes. It was a nice little article giving a simple introduction on the usage of our managed classes along with a very simple mapping. Certainly enough to get people interested in looking for more info.

The more interesting part of the aricle for me though was this:

“By now you probably know that SQL Server 2005 (formerly code-named "Yukon") will include tight integration between SQL Server and the .NET Framework, as well as new XML features. But did you know that Microsoft regularly releases a library of .NET and XML add-ons that works with SQL Server 2000? Called SQLXML, this library can help you with quite a few XML-related tasks.”

It reminded me of something that has been a topic of discussion around the group here lately - the delta between Sql Server 2000 and Sql Server 2005 XML features is actually quite large, larger than you might think if you consider all of the SqlXml web releases. All of the feature we have worked on and release over the last 5 years will be included in SS2k5, making it a long list of new XML technologies for Sql Server. Consider all we've done since 2000:

Web Release 1:

Updategram
Bulkload

SqlXml 2.0

Annotated XSD (instead of XDR)
Client-Side FOR XML
SqlXml Managed Classes
Diffgram Support

SqlXml 3.0

Web Services Support

Current release - SqlXml 3.0 SP2

ID Propagation Support for Bulkload
NULL Support for Web Services

That's not a bad list. Hopefully we'll be able to add a few more things to it to really make Sql Server 2005 special. All leading toward my future plan - “SqlXml - Now includes Sql Server!”

XML Templates and Sql Junkies

irwando — Thu, 19 Feb 2004 00:15:00 GMT

On the front page of SqlJunkies today is an article about XML Templates in SqlXml. In “An Introduction to XML Templates with Sql Server 2000”, Denise White gives a brief overview of what XML Templates are and how to access them over HTTP using our ISAPI extension. There are some good examples in there, mostly using embedded FOR XML queries, and all are download-able from the site.

For anyone who doesn't know, or doesn't want to read the article quite yet, XML Templates are a great little technology for creating dynamic XML documents that have sections populated with data from Sql Server 2000. Basically, you create a valid XML document however you like, and anywhere you want to have data dynamically filled in, you add a special element within our namespace. This could be a “sql:query” element which supports the execution of FOR XML queries and stored procedures, or a “sql:xpath-query” element which indicates the contents are a XPath statement to be executed over a Annotated XSD (XML <-> Relational mapping) file.

There are a variety of ways to execute templates. The article covers executing them through our ISAPI component. However, they can also be executed within applications through ADO / SqlOleDb. Support for templates is built into MDAC 2.7 and 2.8 within the provider. We also ship a set of managed wrappers (SqlXmlCommand) for our native components so the functionality can be accessed within a .Net application. Finally, in the 3.0 release of SqlXml, we added support for accessing these things over web services via our ISAPI component.

So why is this so useful? Well, think about it a bit. Normally if you wanted to do something like this, you'd have to first create the static XML document, walk to the first place to insert dynamic data, execute a query using a different component, fill in the pieces (possibly having to convert the data to XML), and then repeat for any other areas to be filled in. Instead, we take that burden off of you, allowing you to create these templates that we fill in. As mentioned in the article, templates can be parameterized so that the same template can be used repeatedly.

One area Denise did not mention was updates with Updategrams. Updategrams are our technology for updating the database via a diff of XML fragments. Our processor interprets the diff as Inserts / Updates / Deletes against the database depending on elements appearing or not appearing in the before and after images. Updategrams are in fact a part of templates and another tag (”updg:sync”) that can be included within a template. So, in a single file, you could make an update to a Sql Server and then select data back out.

For example. Consider the following template in which I take in several parameters, update the database, and then present the updated data by issuing a XPath against an Annotate schema:

<?xml-stylesheet type="text/xsl" href="updateContact.xsl"?>

<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql"
xmlns:updg="urn:schemas-microsoft-com:xml-updategram">
<sql:header>
    <sql:param name="contactID"></sql:param>
    <sql:param name="name"></sql:param>
    <sql:param name="title"></sql:param>
    <sql:param name="email"></sql:param>
    <sql:param name="phone"></sql:param>
    <sql:param name="fax"></sql:param>

    <sql:param name="bname"></sql:param>
    <sql:param name="btitle"></sql:param>
    <sql:param name="bemail"></sql:param>
    <sql:param name="bphone"></sql:param>
    <sql:param name="bfax"></sql:param>
  </sql:header>

<updg:sync mapping-schema='Contact.xsd'>
    <updg:before>
      <Contact contactID="$contactID" name="$bname" title="$btitle" email="$bemail" phone="$bphone" fax="$bfax"/>
    </updg:before>
    <updg:after>
    <Contact contactID="$contactID" name="$name" title="$title" email="$email" phone="$phone" fax="$fax"/>
    </updg:after>
</updg:sync>

<UpdatedRecord>
    <sql:xpath-query mapping-schema='Contact.xsd'>
      /Contact[@contactID=$contactID]
    </sql:xpath-query>
</UpdatedRecord>
</ROOT>

Here is the annotated XSD file I'm using with it:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:sql="urn:schemas-microsoft-com:mapping-schema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">

<xs:annotation>
    <xs:appinfo>
       <sql:relationship name="Contacts_Customer"
                         parent="Contacts"
                         parent-key="customerID"
                         child="Customers"
                         child-key="customerID"/>
    </xs:appinfo>
</xs:annotation>

<xs:element name="Contact" sql:relation="Contacts">
  <xs:complexType>
    <xs:attribute name="contactID" type="xs:int" use="required" sql:field="contactID"/>
    <xs:attribute name="customerID" type="xs:int" use="optional" sql:field="customerID"/>
    <xs:attribute name="companyName" type="xs:string" use="optional" sql:relationship="Contacts_Customer" sql:relation="Customers" sql:field="companyName"/>
    <xs:attribute name="name" type="xs:string" use="required" sql:field="name"/>
    <xs:attribute name="title" type="xs:string" use="optional" sql:field="title"/>
    <xs:attribute name="email" type="xs:string" use="optional" sql:field="email"/>
    <xs:attribute name="phone" type="xs:string" use="optional" sql:field="phone"/>
    <xs:attribute name="fax" type="xs:string" use="optional" sql:field="fax"/>
  </xs:complexType>
  </xs:element>
</xs:schema>

Sorry for any bad formatting, you may want to copy these into notepad to look at.

Anyway, in the template I've defined a bunch of parameters within the “sql:header“ block. Depending on how this template is being executed, the parameters are passed in at run time (In Denise's article, over http as part of the address. They could, for example, also be passed in via form post.). The “updg:sync“ tags indicate an updategram. In this case, because the element will appear in the before and after block with the same key field (contactID), this is an update. Were I to change that so there was a different contact ID in the before and after, it would appear as two different elements, prompting a delete of the element in the before block and an insert of the one in the after.

After performing the update, I do a simple query against the database to get out the contact I just updated. Within the XML declaration, I also specified an XSL file to execute. This will be done after the query results are returned. Using this, I can build a dynamic website with update capabilities with no coding what-so-ever.

There are limitations here of course. Given that this is not a programming environment, it does not have the richness of ASP.Net. However, if you're still interested in templates, we do provide a set of managed classes (wrappers around our native code) that could be used within ASP.Net pages to execute templates. This would allow you to use templates for retrieving you XML data from Sql Server while still giving you the full power of ASP.Net and the .Net Framework.