Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The ADO Object Model
The Connection object encapsulates the functionality to connect with a data source, read error messages during operations, and manage local transactions for providers that support them. The Command object is used to execute data manipulation statements such as SQL commands or stored procedures that take parameter values. The centerpiece of the ADO object model is the Recordset. It does the heaviest lifting by providing the means to manipulate a collection of rows from a data source. The programmer works with the Recordset by moving a cursor from row to row in the result set, reading and changing values as needed.
The cursor model of the Recordset provides quite a few options for working with result sets from the data source. Depending on the capabilities of the OLEDB provider, the Recordset can manipulate rows and cursors on the server side of a data source or in a client-side cache while implementing different data concurrency locking policies. While powerful, working with the different Recordset options is sometimes confusing and the wrong property entry for the wrong situation can make an application perform poorly.
The Recordset can also represent multiple tabular result sets in a hierarchical arrangement when used with the Microsoft Shape OLEDB provider. This is another unhappy story for ADO, since the Shape syntax is something only a provider developer could love and has not seen overwhelming use by the data access developer community. Most programmers use other techniques to return complex data in a single round trip: SQL batch statements with multiple results sets or XML front ends to databases such as the XML support available for SQL Server 2000.
The Recordset has been very successful in a unique way as a vehicle for carrying data in a multi-tier COM application. The ability of a Recordset to exist disconnected from a data source and marshal-by-value efficiently across COM boundaries without proxy-stub creation and overhead makes it the parameter of choice for distributed application developers, especially those who program with Visual Basic.
The final feature of the Recordset we'll discuss is its XML serialization support. It chooses an XML dialect based on the Advanced Table Datagram (ATG) format to load or save its row data to a storage medium. In case you want to work with the raw XML data instead of file manipulation, ADO has a Stream object that can be the target or source of the Recordset for XML persistence. The unfortunate reality of Recordset XML persistence is the fixed nature of the schema structure used to persist data and the fact that it uses the XML Data Reduced (XDR) schema format that was proposed by Microsoft prior to XML Schema achieving W3C Recommendation status. The programmer is better off working with XML parsing tools such as the Microsoft MSXML parser if customization of XML content is required.
The services of ADO and OLEDB have served the Microsoft development community well over the past couple of years. Unfortunately, they still leave much to be desired. The Recordset has evolved from a simple row-based container to its current position as a hub of complex functionality: cursor models, locking models, and persistence facilities. The number of possible combinations with property settings and OLEDB service provider capabilities can cause subtle problems with data access that are difficult to debug. In addition, the lack of an easily usable hierarchical data scheme and the weak XML support leave the developer wanting more when it comes to developing applications that increasingly rely on disconnected data-access scenarios and complex XML data structures. Fortunately for developers on the Microsoft platform, help is on the way in the form of ADO.NET!