OLE DB is a two-part technology with a foreground interface and a background engine. The background engine processes the queries and retrieves the data. The foreground part of OLE DB contains the programming features that any valid provider needs to expose to its clients. In this area, only Microsoft can establish how, functionally and technologically, OLE DB evolves, by determining the details of the COM interfaces that a provider needs to support. You'll see great improvements with OLE DB 2.5, which fixes design limitations and adds more powerful features. For example, OLE DB 2.5 allows the return of irregular, nontabular recordsets. You can use OLE DB to expose semi-structured and hierarchical data such as XML streams, Word and Excel documents, or the content of a file system directory. In addition, OLE DB 2.5 reduces the amount of information that a consumer needs to know about the required provider. Instead of specifying complex connection and command strings, you can bind directly to the desired recordset via a URL-based syntax. This feature, called direct URL binding, lets you use a connection string such as
http://outlookprovider/inbox/sender='Joe User'
Behind that intuitive URL scheme is the name of the data provider and the command text that asks the provider to scan the Inbox folder and retrieve all the messages sent by Joe User. The latest Microsoft platform Software Development Kit (SDK) partially covers the highlights of OLE DB 2.5.
Because Microsoft considers OLE DB the main technology for data access in the Windows environment, you'll get the support you need to use it for the foreseeable future. Also, SQL Server is Microsoft's principal database server product, so SQL Server providers will immediately reflect new features in OLE DB. Will other vendors' databases accommodate new OLE DB features? In my opinion, OLE DB's weakness is that the only reliable providers are those for SQL Server 6.5 and 7.0. The OLE DB providers for Jet and Oracle reportedly have bugs and incomplete, or inadequate, functionality implementation, which limits their usefulness to developers. Microsoft's OLE DB provider for Oracle isn't great, but it's perhaps the best available. OLE DB 2.1 facilitated multienvironment data access, but the environment for the problem remains. For OLE DB to become a widely accepted standard, all database vendors, and perhaps some third parties, need to release complete providers for various databases and possibly work together to develop them in a better way.
In general, OLE DB has yet to gain the reliability and the acceptance that ODBC has built during the past few years. But OLE DB has the potential to surpass ODBC in terms of supported data sources, flexibility, and programming interface. Moreover, OLE DB's central role in Microsoft's Windows Distributed interNet Applications (DNA) and DNS architectures makes it a serious candidate to replace ODBC. OLE DB promises to be an important technology for planning your future data-access strategies. But don't adopt it blindly.
Why Choose OLE DB?
If you have to decide about OLE DB today, what are the factors to consider? Microsoft designed OLE DB with performance in mind, but architecturally speaking, an OLE DB call has to traverse more layers of code than does a SQL query issued through raw code to the ODBC API. So don't be surprised if you find that a pure ODBC approach is slightly faster. To make up for this inefficiency, OLE DB gives you the ability to aggregate and integrate structurally different types of data and the possibility of using these data types with Web applications.
Don't underestimate the effort necessary to move to OLE DB. This caution applies even if you're already using an object model such as RDO or Data Access Object (DAO), or ADO before version 2.x. Also, proceed carefully if your target database isn't SQL Server. You begin to recoup the cost of moving to OLE DB only when you can exploit the integration with applications and system services that OLE DB allows. If you don't know how to leverage heterogeneous queries, don't have a data warehouse, or don't plan to integrate nonrelational data types (e.g., documents, spreadsheets, email) into the company's data store, you might end up with worse performance! Or you might upgrade your system, but get no concrete advantage.
I usually advise my clients to move to OLE DB only to satisfy urgent business needs (such as those above) that OLE DB addresses well. I also recommend it for new systems because you can design the system to take advantage of OLE DB's strengths. Flexibility, integration, and uniformity are important aspects of OLE DB; if they are integral parts of your business objectives, moving to OLE DB might be cost-effective for you.
Web-based systems are a great territory to employ OLE DB in, although the inferior reliability of some providers might hamper your efforts. However, choosing Microsoft Data Access Components (MDAC), which includes OLE DB as the core technology, lets you leverage Remote Data Services (RDS) on the Web to issue remote calls to components via HTTP. And OLE DB lets you receive, on the client side, disconnected recordsets to work with—not bad, after all!
OLE DB has good and bad points; it isn't magic. It's simply undergoing a process of refinement to become a widely accepted standard. Consider it today, but use it only to get concrete advantages.
End of Article
Prev. page
1
[2]
next page -->
