XML is the most written about, most extolled, and most debated of all of the new technologies. ADO has implemented the capability to persist and construct Recordsets to and from XML since version 2.1. It is far more comprehensive a subject than can be treated here, but that won't keep me from expressing an opinion or two about it. I'm convinced XML is vitally important—for specific special cases. It should, in my opinion not be used as a universal data transmission media. However, the number of interesting (and useful) things you can do with XML is growing.
Unless you've been living in a cave in south Texas (they don't have a local ISP in Big Bend yet), you have been deluged with articles about how XML can solve all of the world's problems. And not all of this information is hype. Yes, XML is another OSFA approach. However, XML makes a lot of sense when you need to transmit information from one application to another and the applications don't know anything about each other (as when talking to space aliens). XML is supported across browser (and operating system) boundaries, and it can be an important tool for moving information from tier to tier.
XML is also a very flexible way to express data structures in a universally understood paradigm for applications that do speak the same language. HTML provides ways to display information, but without context or dynamic behavior. In contrast, XML exposes data content and structure—even hierarchical structure. XML Recordsets can also be updated either directly or indirectly (through procedures) because they expose sufficient DDL source-table information (in some cases) to construct an UPDATE statement WHERE clause. In Chapter 9, I show you how to create an updatable XML-based Recordset.
Conceptually, working with the Web is strangely similar to working with IBM 3270 terminals in the 1970s. That is, the central system generated coded instructions for painting text and crude graphics on the target terminal. The terminal had enough processing power to decode the instructions and paint the boxes and text on the screen at the specified coordinates. The user would see the text, position the cursor using the tab key or other function key, and change or enter new data.We found that the real bottleneck became the central system (what we called the "CPU" in those days). As more users were added, the screens were created increasingly more slowly. However, users were used to delays from 10 to 60 seconds, which most systems could support. HTML has brought us back to this world of simple display languages running remotely on "dumb" browsers. And we're back to waiting 10 to 60 (or more) seconds for the data to arrive and get painted.
This section discusses how to use XML to pass data from an IIS ASP to a generated HTML page. Chapter 9 discusses how to create updatable XML Recordsets.
You can easily persist a Recordset to an XML file using the Recordset.Save method, as shown below, in a normal Visual Basic program or in Visual Basic Script running in an ASP.
rs.Save filename, adPersistXML
The Save method's capability to persist to an XML file has been supported since ADO 2.1. This technique can be used to transport Recordset data, but you have to transport the whole file between layers to do so, which is not practical for many applications.
However, in ADO 2.5 (as first implemented in Windows 2000 and now available for download) you can construct an ADO Stream containing an XML Recordset—even a hierarchical version. A Stream object is simply an in-memory file, or at least it sure looks like it to your code.
Dim stmMyStream as ADODB.Stream Set stmMyStream as New ADODB.Stream rs.Save stmMyStream, adPersistXML
The other ADO 2.5 feature that makes all of this easy is ADO's capability to open persisted Recordsets over HTTP. In addition, the Stream object's ReadText method provides a simple way of extracting a Stream's contents and, when combined with Response.Write, ASP code can return an XML-encoded Recordset without saving anything to a file. The receiving end of this XML can be another Web page that knows how to paint the XML, or it can be your own Visual Basic application, which can reconstitute the XML into a Recordset.
We will spend quite a bit of time in Chapter 9 discussing persisting to Streams because it makes sense (in some cases) to pass the streams back and forth between Web pages (ASP to HTM), between Web pages and Visual Basic programs (Visual Basic to ASP), or even between layers of any of the above.
OSFA: One size fits all. Like socks and airline seats, ODBC and OLE DB are OSFA data interfaces. A "universal" paradigm made to suit everyone—but no one in particular.