What You Need to Know About Persistence

[Previous] [Next]

ADO makes persisting data fairly simple and straightforward. You don't have to use the OLE DB provider to implement persistence; you can simply use the Save and Open methods. Once you've used these methods to store and retrieve data, there's little else you need to know about this feature—except for a few small details, which we'll discuss now.

What Data Gets Stored?

When you call the Save method on the Recordset object, ADO examines the contents of the Recordset and stores most of that data in a file or a Stream object. You can later ask ADO to turn that data back into a Recordset object, but you don't wind up with a carbon copy of your original Recordset object. So how does the resulting Recordset object differ from the original?

If you set the Filter property on your Recordset to an array of bookmarks or to one of the constants in FilterGroupEnum, when you call the Save method ADO will store all the records in your Recordset to the file or the Stream object. If you set the Filter property to a string-based filter, ADO will store only the records visible through that filter.

Calling the Save method on a hierarchical recordset will cause ADO to store data from that chapter and subsequent child chapters. (As you'll recall, a chapter is a set of records in a hierarchy that are associated with the current row in a parent-child relationship.) Data from parent and sibling chapters will not be stored. For example, if you open a hierarchy with customers' orders and order details and call the Save method on the orders level recordset of the hierarchy, ADO will store only the currently visible orders and their associated order details. Customer data, data for orders from other customers, and the details associated with those orders will not be stored. Figure 13-1 shows the contents of the hierarchy. The data highlighted is written to disk when you call the Save method on the orders level of the hierarchy. We'll discuss hierarchical recordsets in more detail in Chapter 14.

Figure 13-1 An example of data stored when you persist a hierarchical Recordset.

You'll probably want to use batch optimistic locking with persisted recordsets so that you can modify data off line and submit those changes later. If you open an updatable client-side Recordset, the ADO Cursor Engine retrieves the metadata required to support updating, such as base column names, base table names, and primary key data.

The value of the Field object's UnderlyingValue property for each field of each record is not stored as part of the metadata. If you resynchronize your Recordset object and store data in this property, the data will be lost when you persist your Recordset. Therefore, if you persist that Recordset, reopen it later, and attempt to resubmit a pending change, ADO will act as though this were the first update attempt and will again use the values in the OriginalValue properties of the Field objects in the WHERE clause of the action query.

Another piece of metadata ADO doesn't store with your file or stream is the current position in the recordset. Regardless of which record you were viewing prior to persisting the recordset, when you reopen your Recordset object, you'll see the first record. Similarly, data such as the original value of the Source property is lost when you persist and reopen your Recordset. This means that an attempt to call the Requery method on the reopened Recordset will fail. Maybe in a future version of ADO this data will be stored to make this functionality possible.

Which Format Should You Use: ADTG or XML?

Prior to the release of ADO 2.1, there was only one format that you could use to persist your data: Advanced Data TableGram (ADTG), which is a proprietary data format. But, as mentioned earlier, ADO 2.1 made the XML format available for persistence.

XML is a hot topic in the programming community for a number of reasons—it's self-describing, it's generally associated with web-based applications, and all you need to use it is a parser.

But that doesn't mean you should always persist your Recordset object in XML rather than in ADTG. Yes, XML is much more flexible, but that flexibility comes with a performance penalty. When you ask ADO to reopen a Recordset object that has been persisted to a file or a stream in XML format, ADO uses the Microsoft Internet Explorer XML parser to convert the data. When a Recordset has been persisted in ADTG format, ADO converts the data back into a Recordset object without using an external parser. For small recordsets, the difference in performance is negligible. However, for large recordsets, it can become an issue for two reasons: you're moving data through an extra component in the XML parser, and the XML format is generic text-based data while the ADTG format is designed specifically for Recordsets.

There is more than one way to self-describe the data stored in a Recordset object. One of my colleagues who works closely with the ADO product group explained that you could use ADO to retrieve data with a firehose cursor, persist that data in XML format, and then manipulate that data and insert the metadata that the ADO Cursor Engine requires to support updating into the XML file. I thought this was a great idea and was able to make it work, but then found that my code wasn't behaving as I expected when I used ADO 2.5. That's when I noticed that the XML format ADO uses changed from ADO 2.1 to ADO 2.5. This means that if you write code to manipulate the XML data that ADO generates, your code might work only for a specific version of ADO. C'est la vie. So keep in mind that there's no guarantee the ADO development team will continue to use the same XML format in future versions of ADO.