The Adonet Approach to Data Access

If you've used Microsoft DAO or ADO, you're accustomed to dealing with Recordset objects. At a basic level, a Recordset object contained a two-dimensional arrangement of data, although that's somewhat of an oversimplification. A Recordset object contained a set of columns, called "fields," each of which corresponded to an existing or derived column in a database. For example, running the SQL query select * from Customers against the Northwind database, the server would return the set of all rows and all column values for the existing columns in the Customers table. However, if you run the following query, the server will return a set of rows containing only one derived column, named FullAddress, consisting of the concatenated values from the three columns named in the query, separated by commas.

SELECT Address + ', ' + City + ', ' + PostalCode AS FullAddress FROM Customers

So, a simple recordset was essentially a table containing rows and columns. The recordset maintained a position pointer set to the current row. Recordsets exposed data through a collection of Field objects. A Field object represented the intersection of each row and column in the recordset—in other words, a single cell in the table. You could imagine a recordset as appearing like Figure 13.7.

Figure 13.7: Simple Recordset object

The Field objects contained the data values. In addition to data values, you could query a Field object to determine its name (the column name or alias name), the data type, its maximum length, its default value, and many other properties.

Later versions of ADO added the capability for a recordset field to contain another recordset. By doing that, recordsets could represent hierarchical or multidimensional data. For example, a list of customers from one table might be related to a list of orders from another table. If you simply combined the two tables using a simple query, the data for each customer would appear once for each order made by that customer in the result set. However, using a shaped query, you could combine the related data so that one of the columns in the Customers table would contain another recordset that in turn contained the Orders data for that customer. The column that contains the Orders recordset is called a chapter column. Such shaped queries quickly became complex, but you can imagine a simple version looking something like Figure 13.8.

Figure 13.8: Shaped recordset in which each customer record has a chapter column consisting of another recordset containing multiple orders for that customer

Was this article helpful?

0 0

Post a comment