Mark Wilson I am the creator of TopXML. I am available for international and local (Australia) contracts. I am a Solution Architect/Business Analyst. I have worked in IT in several countries (NZ, Australia, South Africa, UK) building and training teams for government and very large non-governmental organizations. I am ex-Microsoft Consulting Services. I wrote the first book on Microsoft XML published in 2000 called XML Programming with VB and ASP. Most recently I have been building tools for the SEO industry. Ask me for a 37 point SEO health-checkup for your website.
First posted :
03/24/2008
Times viewed :
241
.NET Managed Classes
Now that we know about the concepts of data access in SQLXML it is time to
actually look at the managed classes to leverage them. SQLXML ships with COM
objects as well as with managed code classes to interact with SQL Server in an
XML-centric fashion. In the next four sections we will investigate the managed
classes and see how we can issue XPath queries, send Updategrams, how we can
interact with the DataSet class. Last but not least we will also take a look
how we need to process errors occurring during SQLXML operations. Table 15.8
lists the managed classes of SQLXML.
1.8 The
Microsoft.Data.SqlXml namespace contains four classes to access the SQLXML
functionality from .NET applications.
Managed Class
Purpose
SqlXmlCommand
The command class of the SQLXML provider. Can perform queries using
queries stored in XML documents called XML templates. Can be used to update
data using an Updategram or a Diffgram. Also provides support for client side
XML processing.
SqlXmlParameter
Used with a SqlXmlCommand object to provide parameter values for
parameterized SQL statements, Templates and Updategrams.
SqlXmlAdapter
The Adapter class for the SQLXML provider. Allows you to fill a DataSet
with data from a SqlXmlCommand.
SqlXmlException
The SqlXmlException excapsulates error information returned by SQL Server.
Notice that the SQLXML library does not expose a connection class. Data
access with SQLXL never maintain any connections, which forces all your queries
onto separate connections and isolates all your database updates. Consequently,
there is no concept of distributed transactions spawning across multiple
commands or databases that can be committed and rolled back with SQLXML. The
only transacted operations are the changes defined by a single <sync>
block of an Updategram. These only run in the context of a local SQL Server
transaction. Local transactions offer much better performance than the
distributed transactions managed by COM+/.NET ServicedComponents, but they only
run inside a single command execution and within a single database instance.
Furthermore, you need to carefully design your Updategrams to tailor the
transaction boundaries to the needs of your application. So much for the class
that is not there, now let’s look at the classes that are.
