Universal Data Access and OLE DB

Customer Requirements for Data Access Technologies High-Performance access to data Reliability Vendor Commitment Broad industry support

Universal Data Access UDA is a platform for developing multitier enterprise applications that require access to diverse relational or nonrelational data sources across intranets or the Internet. Provides high-performance access to a variety of data and information sources on multiple platforms. it does not require expensive and time-consuming movement of all corporate data into a single data store

Universal Data Access UDA consists of a collection of software components that interact with each other using a common set of system-level interfaces defined by OLE DB.

Universal Data Access

UDA Component Data providersData providers are components that represent diverse sources of data such as SQL databases, indexed-sequential files, spreadsheets, document stores, and mail files. (RowSet) ServicesServices are components that extend the functionality of data providers by implementing extended interfaces where not natively supported by the data store. ConsumersConsumers are components that consume OLE DB data. Examples of consumers include high-level data access models such as ADO. (VB,C++,Java)

Universal Data Access The strength of UDA is it is delivered through a common set of modern, object-oriented interfaces(Component Object Model:COM) –The richest integrated services –The widest choice of tools from multiple vendors using multiple development languages –The largest customer base for customizable applications and reusable components –Proven interoperability with users’ and developers’ existing investments

COM interfaces OLE DBLow level application developmentOLE DB ADOHigh level application developmentADO

OLE DB OLE DB is Microsoft’s strategic strategic system-level programming interface to data across the organization OLE DB is an open specification designed to build on the success of ODBC by providing an open standard for accessing all kinds of data. OLE DB is designed for relational and nonrelational information sources, including mainframe ISAM/VSAM and hierarchical databases; and file system stores; text, graphical and geographical data; custom business objects; and more.

ActiveX Data Object ADO is application-level programming interface to data and information over OLE DB data. ADO provides consistent, high-performance access to data and supports a variety of development needs, including the creation of front-end database clients and middle-tier business objects, using applications, tools, languages or Internet browsers. ADO is designed to be the one data interface needed for one-to-multitier client/server and Web-based data-driven solution development.

ActiveX Data Object ADO provides an easy-to-use application level interface to OLE DB, which provides the underlying access to data. ADO is implemented with a small footprint, minimal network traffic in key scenarios, and a minimal number of layers between the front end and data source — all to provide a lightweight, high- performance interface. ADO was designed to combine the best features of - and eventually replace - RDO and DAO

ADO provides several advantages to programmers: –Ease of use –Programming language neutral. ADO can be used from languages such as Visual Basic, Java, C++, VBScript, and JScript. –Provider neutral. ADO can access data from any OLE DB source. In addition, ADO adapts gracefully to support less functional OLE DB providers. –No loss of OLE DB functionality. ADO allows C++ programmers access to the underlying OLE DB interfaces. –Extensible. ADO can dynamically expose properties specific to a data provider via collections of provider properties. In addition, it provides type extensibility by allowing access to COM objects exposed as column values.

Design Goal of Microsoft Data Access Component MDAC is a set of redistributable technologies that implement Universal Data Access. MDAC consists of the latest versions of ActiveX Data Objects, OLE DB components and Open Database Connectivity.

Universal Data Access Architecture

Comparison of the ADO and DAO/RDO Architectures

How ADO and OLE DB work over the Internet

OLE DB

ADO Object Model

Connection, Command, and Recordset objects are top-level objects that you can create and destroy independently of each of the other objects. Parameter must be associated with a Command before you can use it. Field, Error, and Property objects each exist only within the context of their parent objects, and can’t be separately created.

ADO Object Model Connection object encapsulates the OLE DB Data Source and Session objects. Represents a single session with the data source. Connection object defines properties of the connection Assigns the scope of local transactions, Provides a central location for retrieving errors, And provides a point for executing schema queries.

ADO Object Model Command object encapsulates the OLE DB Command object. Command specifies the data-definition or data- manipulation statement to be executed –case of a relational provider, this is an SQL statement. Command object allows you to specify parameters and customize the behavior of the statement to be executed. A collection of Parameter objects exposes the parameters

ADO Object Model Recordset object encapsulates the OLE DB Rowset object. Recordset object is the actual interface to the data, whether it is the result of a query or was generated in some other fashion. Recordset object provides control over the –locking mechanism used –the type of cursor to be used –the number of rows to access at a time –and so on.

ADO Object Model Recordset object exposes a collection of Field objects that contain the metadata about the columns in the recordset, such as the name, type, length and so on. Recordset object to navigate through records and change data (assuming the underlying provider is updatable).

ADO Object Model Each of the top-level ADO objects contains a collection of Property objects Property object allows ADO to dynamically expose the capabilities of a specific provider, because not all data providers have the same functionality It is important for the ADO model to allow you to access provider-specific settings in a dynamic way