Integrating XML and ADO
Starting with version 2.1, ADO provides the ability to automatically persist recordsets in XML. Dino Esposito explores the benefits of this feature in B2B applications.
January 2, 2001
One of the most common ways to use XML is as a data-transfer format within business-to-business (B2B) applications because such applications need to exchange collections of records shaped in many possible ways. For example, an application might need data in a tabular as well as a hierarchical format. XML is a great data-transfer format, but nothing more. XML simply provides a universal infrastructure to describe data in a way that applications can easily understand and process. Because data always comes from databases, any integration feature that glues together XML and data access technologies is most welcome.
ActiveX Data Objects (ADO) is Microsoft's preferred technology to talk to data providers from within ASPs and high-level development tools such as Visual Basic (VB) and Windows Script Host (WSH) script applications. ADO uses the Recordset object to collect the records to work on. ADO recordsets are just the right fuel for XML in a B2B scenario.
Starting with version 2.1, ADO provides the ability to automatically persist recordsets in XML. The Recordset object exposes a method called Save that can serialize to disk the in-memory representation of the recordset. The following VB code shows how to save a recordset to disk using XML as the persistence format (note that the .xml extension on the filename is a matter of choice):
Dim oRS as New ADODB.Recordset' Now populates the recordsetoRS.Save "file.xml", adPersistXML
Microsoft uses a particular XML schema to store a recordset. At first glance, the XML document structure might seem overwhelming and unnecessarily complex. However, it contains all the information it needs to implement several additional features. In other words, when you export an ADO recordset to a disk file format, the recordset doesn’t lose any of its potential functionality. Also when you save a recordset to disk as XML, the recordset remains an ADO Recordset object.
By calling the Save method, you simply move the in-memory ADO Recordset object to a different storage medium. The object maintains the same functionality, and you can work on disk recordsets the same way in which you work with those in memory. This deliberate duality has some cool side effects, one of which is that you can reload a recordset from an XML disk file. The necessary code looks like this:
oRS.Open "file.xml",,,, adCmdFile
This feature smooths the way for applications that need to work the same way, regardless of their network connection's status. You connect to a database—from a Web application or a from client/server application—grab your recordsets, and start working on them. Suppose that while you're working, you lose your network connection and the application can't submit changes to the remote database. Thanks to XML recordset persistence, you can save the recordset status to the local disk in XML format. The next time the application starts, it checks a specific temporary folder. If the application finds a certain XML file, the application uses the XML file's content to reload the working recordset and properly initialize the application.
XML persistence is only one of the features that ADO makes available. In my next column, I'll review in more detail the XML schema used and some tricky aspects of the XML and ADO integration.
About the Author
You May Also Like