OLE DB white paper

You can read through this white paper, or choose a topic of interest from this list:

• What is OLE DB?
• Who Uses the OLE DB Interfaces?
• OLE DB is Not a Replacement for ODBC
• Summary

Businesses are increasingly discovering the need to build solutions that span desktop, mid-range, mainframe, and Internet technologies. The variety of data stores that are present in any business today, and the many ways in which they are accessed, create barriers to developing applications that can bridge both the new and the old technologies. As a result, new requirements emerge for middleware that enables a new class of applications to be easily built and managed.

OLE DB is a specification for a set of data access interfaces designed to enable a multitude of data stores, of all types and sizes, to work seamlessly together. These interfaces comprise an industry standard for data access and manipulation that can ensure consistency and interoperability in a heterogeneous world of data and data types.

OLE DB goes beyond simple data access by partitioning the functionality of a traditional relational database into logical components, and the events needed for those components to communicate. Developers can use these interfaces to define very simple data providers as well as fully relational databases. This is a strategic part of Microsoft's enterprise infrastructure for component-based computing. Components can be thought of as the combination of both process and data into a secure, reusable object. As a result, it often makes sense to treat components as both consumers and providers of data at the same time. Since the OLE DB specification is a definition of how databases interoperate at various levels, components can be built using OLE DB to behave as a table, even though very complex computing processes can actually occur between the data sources and the consuming applications. This capability will have considerable impact on how multi-tier applications are assembled.

The OLE DB interfaces are useful to all software vendors whose products manage data in some way. Since OLE DB provides a way for any type of data store to expose its data in a standard, tabular form, new opportunities will arise that don't exist today. Some examples are discussed here:

• The health care industry makes extensive use of the MUMPS database. The format of MUMPS does not allow easy integration with other data stores and, as a result, is a barrier to the development of new systems that can access the old.
• Profitability in the financial services industry is based on a trader's ability to receive, analyze, and complete trades quickly based on an integrated desktop. Yet developers are constantly dealing with a multitude of real-time data feeds for news and stock with few standards among them, and face a slow, difficult development task as a result.
• In manufacturing, CAD/CAM systems store a plethora of critical data about parts that must be completely up-to-date. Yet it is currently impossible to integrate the part information in a CAD/CAM tool with a manufacturing system's parts database.
• Insurance providers are increasingly deploying integrated desktop applications that combine the power of desktop productivity tools with mainframe-based information, so field office agents can respond to their customers. Yet developers of these kinds of solutions are faced with very different programming models for making these different environments work together.
• Across all businesses, e-mail is becoming a mission-critical information source. Yet it is currently impossible to perform a simple query that would produce all the e-mail interactions in a given month with a business's top ten customers.

Data Providers

As can be seen in the earlier examples, there are many reasons to simplify data access in the corporate world. Enabling a variety of diverse data sources to share information is essential to corporate decision making.

With the initial release of the OLE DB SDK, OLE DB-compliant data consumers will be able to efficiently access all relational databases through existing ODBC drivers. Therefore, Microsoft's plan is to work primarily with non-SQL database vendors to support the OLE DB interfaces. These data sources range from very simple formats like log files and ISAMs through the most complex formats, such as IMS, ADABAS, or e-mail stores.

Additionally, the OLE DB SDK provides a component that implements common functionality associated with managing a rowset. This component makes it easier for data providers to expose the rowset interfaces on top of their data.

The advantages of OLE DB continue to grow as a broad base of support from a wide array of database vendors becomes available.

Data Consumers

The OLE DB data consumer is any piece of system or application code that needs access to a broad range of data, including development tools, languages, and personal productivity tools. Microsoft is actively encouraging a broad set of tools vendors to write to the OLE DB specification. The goal is to get complete tool support for OLE DB.

Data Service Providers

As mentioned earlier, OLE DB goes beyond simple data access by partitioning the functionality of a traditional relational database into logical components, and the events needed for those components to communicate. The intent is to develop database components, such as query processors or cursor engines, as stand-alone products that can seamlessly intergrate with existing OLE DB-compliant data providers.

Business Component Developers

As applications broaden their reach to end users through the corporate networks and to customers through the Internet, applications based on reusable components that can execute locally (for graphical work) or remotely (for computational work) become increasingly important. Microsoft is actively building a suite of tools and an infrastructure to make distributed applications based on these technologies both scaleable and manageable. OLE DB will play an important role in the future development of vertical applications based on business-centered components.

For example, when a developer decides whether to design a new application using a classic client/server approach, or using a three-tier approach, there are certain tradeoffs. For instance, it is much easier to attach a visual control directly to a table than it is to write code to query a component and load the control. On the other hand, it is better to avoid linking controls directly to data structures so the database can evolve without impacting all dependent clients. The solution is for business components to use OLE DB to both consume data from data providers, and at the same time expose its result set after data access and processing as a simple OLE DB tabular rowset. This provides the best of both worlds—the capability to attach to a rowset, while maintaining the required abstraction from the true data tables.

In addition, if the returned rowset from the component is very large, it may need to be queried for subsets of information. In this case, the developer can treat the returned rowset like a table, and can use an OLE DB-compliant query processor to query and update subsets.

Finally, when data changes, events are required to allow notification between dependent components on a single desktop, and between the remote database and any dependent desktop components. OLE DB defines the events required synchronize the entire application environment as data changes occur. This is a critical element when writing database-centered applications using components.

The ODBC technology and third-party market have matured to a point at which ODBC is an ideal technology for accessing SQL databases. As a result, an integral part of OLE DB is a new OLE DB driver manager that enables OLE DB consumers to talk to ODBC providers. The following information can guide your choice of which technology to use:

• If you are accessing standard relational databases from a non-OLE environment, ODBC is the best choice.
• If you want to expose a data interface to non-SQL data, OLE DB is the best choice.
• If you are programming in an OLE environment, OLE DB is the best choice.
• If want to build interoperable database components, OLE DB is the only choice.
• Technical differences between the two interfaces include:

There are an increasing number of data stores and data types spread across computer systems. Increasingly, business applications need access to a multiplicity of internal and external data sources simultaneously. OLE DB is a forward-thinking technology targeted at these kinds of applications. This is a low-level technology directed toward software vendors whose products provide or consume data. The result of ISV support for OLE DB will be availability of high-level tools and languages from many vendors. These tools will be able to access a wide variety of data sources without the confusion of different proprietary APIs.

As application developers move to solutions designed as reusable components, OLE DB enables business-centered components to behave and communicate like mini-databases, both as data consumers and providers. This capability is the basis for new, simpler ways to build applications based on components.

OLE DB is an integral part of a comprehensive suite of products and technologies from Microsoft designed to take advantage of the trend towards network-based, distributed computing solutions.

Features and Benefits of OLE DB:

• Access to all your corporate data regardless of storage format or location

  This capability extends across corporate data as well as Internet data, and across all types of data providers beyond SQL databases.

• Simplified programming model for corporate developers

  When a developer uses a tool or language that supports OLE DB, different data sources can behave as a single, homogeneous source. For instance, Microsoft will provide a high level, object oriented way to access all OLE DB data through a new version of AcitiveX Data Objects (ADO). From ADO, developers can create business applications that link many data sources.

• Interoperable data-centered components

  Business components can excrete data change events, consume OLE DB data, and provide OLE DB data. This way, business components can perform very complex processing, and synchronize with other components, yet expose simple, table-like interfaces.

• Components can act as virtual tables for quicker application development

  Most graphical development tools automate loading result sets from queries directly into visual controls. Today, calling components requires more programming to access the result set and load the visual controls. When business components expose their results as OLE DB-based tabular data, development tools can treat them as a simple table, even though their application is using reusable, distributed components.

• Integration with the suite of Microsoft's application development products and technologies

  OLE DB is a useful technology in its own right, but becomes compelling as Microsoft's broad suite of enterprise tools and technologies integrate and extend each other's capabilities. For instance, the transaction processing component of OLE DB is being defined and implemented by Microsoft's OLE-based transaction product currently code-named Viper, and Viper will utilize OLE DB for data access.

• Full integration with ODBC

  OLE DB data consumer tools and languages have full access to all ODBC drivers and ODBC-based data.