Microsoft Corporation
What is OLE DB?
OLE DB, an interface for data access, is Microsoft's component database architecture designed to provide access to data regardless of location or type. OLE DB is a freely published specification designed with industry-wide participation through Microsoft's Open Process. Widespread adoption of OLE DB will facilitate development of an industry standard for data access and manipulation to both SQL and non-SQL data sources, thereby providing consistency and interoperability in an enterprise's network from the mainframe to the desktop and across the Internet.
Is OLE DB intended to replace ODBC?
No. Microsoft's Open Database Connectivity (ODBC) industry-standard SQL-based data access interface will continue to provide a unified way to access SQL-based data as part of the OLE DB specification. OLE DB is fully able to leverage existing ODBC drivers due to an OLE DB-based database component provided in the SDK called the ODBC Provider.
Is ODBC Version 3.0 required for compatibility with OLE DB?
No. We support existing ODBC drivers.
Won't OLE DB to ODBC add another layer to ODBC and make it slow?
No new layers are added. The ODBC Provider essentially replaces the ODBC Driver Manager, so the only material difference is that it communicates to the client via the OLE DB APIs rather than the ODBC APIs.
Why are you using OLE rather than ActiveX™ in the name?
OLE DB is a C++ API. ActiveX represents a language-neutral interface based on the ActiveX component technology. As a result, we stayed with the OLE naming convention.
Who uses OLE DB?
OLE DB is targeted towards sophisticated developers building a data access infrastructure into all products that either consume or provide data. This includes software vendors of development tools, database products, report writers, mail stores, and so on. The flexibility of OLE DB gives it a very broad audience. Large corporations who build their own infrastructure will also be interested in OLE DB.
Since OLE DB is a C++ API, how will the average business solution developer take advantage of OLE DB?
Microsoft will provide a set of high-level data access objects called ActiveX Data Objects (ADO). This will enable access to the full set of OLE DB functionality in an object-oriented, language-neutral way.
You already have Data Access Objects (DAO) and Remote Data Objects (RDO). Is ADO a third way of object-oriented data access from Microsoft?
We intend for ADO to be an evolution of our earlier object models. Over time, all our products will standardize on ADO and OLE DB.
DAO and RDO are not redistributable by third-party vendors today. Is ADO going to be redistributable along with OLE DB?
Yes. We expect ADO to become broadly supported as an object-oriented data access interface for solutions developers.
Is ADO intended to compete with Sun's JDBC?
No. JDBC is a simplified set of object interfaces on top of ODBC for use only within the Java environment. ADO is based on ActiveX technology, making it a broadly accessible, language-neutral way to get to data. And since ADO is based on OLE DB, it will have better accessibility to more kinds of data and data services. Also, the component nature of OLE DB and ADO makes them better suited for data access in disconnected environments such as the Internet.
What does OLE DB do that ODBC doesn't do?
If you are accessing relational data from a C API world, then ODBC continues to makes sense as your primary API. If you are getting to a wider variety of data from a Component Object Model (COM) environment, then OLE DB is your best choice because it goes beyond SQL-based access methods. Since OLE DB will heavily use COM and Distributed COM (DCOM), OLE DB is better for use on the Internet and can take advantage of features in COM such as cross-process notifications.
In addition, OLE DB lowers the barriers for data access compared to ODBC. An ODBC data source must provide functionality equivalent to a SQL query in order to expose its data. In OLE DB it is possible for simple, non-SQL data sources to expose their data very efficiently without the need for a complex SQL processor.
Are you planning cross-platform support for OLE DB?
Yes. Our goal is to have OLE DB available wherever COM and DCOM are available. Since OLE DB is mostly a specification, porting issues are simplified.
Does OLE DB support transactions?
Yes. Part of the specification is the transaction interfaces used by the Distributed Transaction Coordinator (DTC) product that ships in SQL Server.
What about XA transactions?
Yes. DTC supports XA as well.
You say the OLE DB spec identifies separate components of a database. Is SQL Server using these?
Yes, SQL Server is componentizing internally based on the OLE DB specification. It will expose a native OLE DB interface in addition to its existing ODBC and DB Lib interfaces.
Will SQL Server sell itself as a bunch of components?
No. OLE DB is not intended to replace the way databases are packaged. The goal is to add value to the wide variety of data sources in existence.
Why is SQL Server supporting OLE DB?
The same reason any data source might. The SQL Server team wants to provide a standard, COM-based access to SQL Server data, as well as enable access to more kinds of heterogeneous, possibly distributed, data sources from within the SQL Server query processor.
How do you ensure that different components from different vendors work well together?
First, by encouraging them to write OLE DB-compliant components as described by the OLE DB programmers reference, Second, by providing test suites to ensure interoperability as part of the SDK. Finally, by organizing periodic "connectathons" where vendors get together and test with each other's products.
Do you support standard SQL?
Yes. OLE DB leverages SQL in many aspects of its design. SQL-based OLE DB data sources use SQL as their language for data definition and manipulation. OLE DB schema information is based on SQL. OLE DB encourages SQL data sources to be fully SQL 2 compliant, and we plan on aligning with SQL 3 when it becomes available in the future.
Will this technology be given to a standards body?
That may make sense down the road. We are currently releasing version 1.0 of this product, and are working closely with key partners. As the feature set stabilizes, a standards body becomes more attractive. This is exactly how we created the ODBC standard. With the release of ODBC 3.0, it will be aligned with the standards bodies in fall 1997.
Is OLE DB your object/relational strategy?
It is an important part of our o/r strategy. OLE DB will be the integrating force for all COM-based sources of data. For instance, OLE DB will allow Microsoft® Excel to be treated as an alternate data type with many special methods. Since many of the widely available objects in the world today are based on COM, this will be a valuable addition.
What about universal data stores that Informix and Oracle are building? Does OLE DB compete with these?
No. Those databases are fine for times when you need to store many different data types in a single location. The goal of OLE DB is to allow access to distributed data of all types. The two technologies are very complementary.