ADO Record Object

[Previous] [Next]

Traditional database programmers will not find the Record object useful (because the OLE DB providers for traditional relational databases don't support it), but they're not the programmers for whom the ADO development team built this object. The name of this object might make you think that it's used to interact with a single record in a Recordset object. Although this is probably the easiest way to envision the Record object, the object does a lot more than simply hold a record's worth of data that is already available in a Recordset.

Hierarchical Data

Many data stores expose data in hierarchies. File systems, for example, contain files and directories. While a file might resemble a row in a table in a traditional relational database, a directory resembles both a row in a table and a table. The Record object is designed to handle data in a similar manner. Call a Record object's GetChildren method, and you'll receive a Recordset object that contains the child data (the records) associated with that Record object.

Nonrectangular Data

In some cases, you can use the Record object to access more information than what's accessible through the Recordset object. Imagine the records in a Recordset as a grid: each record (row) contains the same set of fields (columns). This rigid, rectangular structure can prevent you from accessing certain data—creating, if you'll pardon the pun, gridlock.

Once again, take data in a directory as an example. Files and subdirectories have some of the same attributes, such as the name and the date created, but they also expose unique attributes. For example, files generally have an application associated with them, and directories generally contain information about whether they're visible as a network share. Because this structure of files and subdirectories within a directory exposes different attributes, the attribute data is considered nonrectangular.

If you were to look at the files and subdirectories of a particular directory in terms of a Recordset object, you'd see only the common attributes (columns of data) that are exposed by both the files and subdirectories. Examining a file and a subdirectory as individual Record objects will expose all the attributes of both structures. Therefore, the Count property of the Fields collection might be larger when you look at a record of data in a Record object than when you look at that same record in a Recordset object, as shown in Figure 6-1.

Figure 6-1 Fields available in a Recordset object and a Record object.

I've explained this concept to a number of programmers. Some "get it," and others don't. Chances are, if you can't think of any cases in which this functionality would be useful, it's because you haven't encountered a scenario that required access to nonrectangular data. If that's the case, don't strain yourself trying to envision handy uses for this functionality. Just know it's available in case you need it.