Universal Data Access provides a common way to access data regardless of the form in which it is stored. In a typical business situation, a vast amount of information is stored outside of corporate databases. This information is found in file systems (such as FAT or NTFS), indexed-sequential files, personal databases (such as Access), spreadsheets (such as Excel), project planning applications (such as Project), and email (such as Outlook).

Accessing this data using the various associated applications presents a major bottleneck in workflow or at least an annoyance. Most companies find themselves in this situation and deal with the problem by consolidating the information in a database management system (DBMS). However, such a move is expensive, time consuming, and in many cases not practical.

The alternative is to develop a Universal Data Access solution. OLE DB and ADO provide Universal Data Access capability. Of the two, OLE DB is the more performance intensive and is recommended for use with Visual C++ applications.

Universal Data Access implies two capabilities: the first is distributed query or uniform access to multiple (distributed) data sources and the second is the ability to make non-DBMS data sources accessible to database applications.

• Distributed query

  The ability to access data uniformly on multiple (that is, distributed) data sources. The data sources can be of the same type (such as two separate Access databases) or of different types (such as a SQL Server database and an Access database). Uniformly means that you can meaningfully run the same query on all data sources.

• Non-DBMS access

  The ability to make non-DBMS data sources accessible to database applications. Examples of DBMS data sources include IMS, DB2, Oracle, SQL Server, Access, and Paradox. Examples of non-DBMS data sources include information in file systems, email, spreadsheets, and project management tools.

Consider a scenario in which a sales department needs to find all email messages received within a one-week period from customers in a certain area. This query might require a search on an email application's mailbox file and a search on an Access table of customers to specify the customers' names. While Access is a DBMS application, Outlook is not.

OLE DB allows you to develop applications that access diverse data sources, whether they are DBMS or not. OLE DB makes universal access possible by using COM interfaces that support the appropriate DBMS functionality for a given data source. COM reduces unnecessary duplication of services and maximized interoperability not only among data sources but also among other applications.

This is where COM comes in. OLE DB is a set of COM interfaces. By accessing data through a uniform set of interfaces, you can organize a database into a matrix of cooperating components.

Based on the COM specification, OLE DB defines an extensible and maintainable collection of interfaces that factor and encapsulate consistent, reusable portions of DBMS functionality. These interfaces define the boundaries of DBMS components such as row containers, query processors, and transaction coordinators, which enable uniform transactional access to diverse information sources.

Typically, OLE DB applications are written as DLLs, but its COM implementation overcomes the disadvantages of DLLs (such as naming and version problems) by using componentized code. In OLE DB, you call interfaces or access other components using their globally unique identifiers (GUIDs).

Finally, COM keeps track of component usage by using reference counting. When you call a method on an interface, the reference count is incremented; when the method returns, the reference count is decremented. When the count equals zero, the component to which the method belongs is released.

Data source objects allow you to connect to a data source such as a file or DBMS. A data source object creates and manages the connection and contains permissions and authentications information (such as login name and password). A data source object can create one or more sessions.

A session manages a particular interaction with the data source to query and retrieve data. Each session is a single transaction. A transaction is an indivisible work unit defined by the ACID test. For a definition of ACID, see Transactions.

Sessions perform important tasks such as opening rowsets and returning the data source object that created it. Sessions can also return metadata, or information about the data source itself (such as table information).

A session can create one or more commands.

Commands execute a text command such as a SQL statement. If the text command specifies a rowset, such as a SQL SELECT statement, the command creates the rowset.

A command is simply a container for a text command, which is a string (such as a SQL statement) passed from a consumer to a data source object for execution by the provider's underlying data store. Typically, the text command is a SQL SELECT statement (in which case, because SQL SELECT specifies a rowset, the command automatically creates a rowset).

Rowsets expose data in tabular format. An index is a special case of a rowset. You can create rowsets from the session or the command.

Schema Rowsets

View Objects

Only OLE DB uses the concept of accessors. An accessor describes how data is stored in a consumer. It contains a set of bindings (called a column map) between rowset fields (columns) and data members that you declare in the consumer.

Transaction objects are used when committing or aborting nested transactions at other than the lowest level. A transaction is an indivisible work unit defined by the ACID test. ACID stands for:

• Atomicity: cannot be divided into smaller work units.
• Concurrency: more than one transaction can occur at a time.
• Isolation: one transaction has limited knowledge about changes made by another.
• Durability: the transaction makes persistent changes.

Enumerators search for available data sources and other enumerators. Consumers that are not customized for a particular data source use enumerators to search for a data source to use.

A root enumerator, shipped in the Microsoft Data Access SDK, traverses the registry looking for data sources and other enumerators. Other enumerators traverse the registry or search in a provider-specific manner.

Any interface on any OLE DB object can generate errors. Errors contain additional information about an error, including an optional custom error object. This information is contained in an HRESULT.

Notifications are used by groups of cooperating consumers sharing a rowset (where sharing means that the consumers are assumed to be working within the same transaction). Notifications enable cooperating consumers sharing a rowset to be informed about actions on the rowset performed by their peers.

The OLE DB Templates, which are part of ATL (Active Template Library), make the high-performance OLE DB database technology easier to use by providing classes that implement many of the commonly used OLE DB interfaces. Along with this template library comes wizard support for creating OLE DB starter applications.

This template library contains two parts:

• OLE DB Consumer Templates Used to implement an OLE DB client (consumer) application.
• OLE DB Provider Templates Used to implement an OLE DB server (provider) application.

To use the OLE DB Templates, you should be familiar with C++ templates, COM, and the OLE DB interfaces. If you are not familiar with OLE DB, see OLE DB Programmer's Reference.

For more information, you can:

• Read the topics about the OLE DB Consumer Templates or OLE DB Provider Templates.
• Create an OLE DB consumer or OLE DB provider.
• See the list of OLE DB consumer classes or OLE DB provider classes.
• See the list of OLE DB templates samples.
• See OLE DB Programmer's Reference (in the Windows SDK).

The OLE DB consumer attributes provide a convenient way to create OLE DB consumers. The OLE DB attributes inject code based on the OLE DB consumer templates to create working OLE DB consumers and providers. If you need to specify functionality not supported by the attributes, you can use the OLE DB Templates in conjunction with attributes in your code.

The MFC library has one class, COleDBRecordView, that displays database records in controls. The view is a form view directly connected to a CRowset object and displays the fields of the CRowset object in the dialog template's controls. It also supplies a default implementation for moving to the first, next, previous, or last record and an interface for updating the record currently on view. For more information, see COleDBRecordView.

In the cases where the OLE DB Templates do not support OLE DB functionality, you need to use the OLE DB interfaces themselves. For more information, see OLE DB Programmer's Reference in the Windows SDK.