Databases Reference
In-Depth Information
stores. The OLE DB standard was created for client applications to have a
uniform interface from which to access data. Such data can come from a wide
variety of data sources using this interface, such as Microsoft Access, Mi-
crosoft Project, and various database management systems.
Microsoft provides a set of OLE DB data providers to access data from sever-
al widely used data sources. These OLE DB providers are delivered together
in a package called MDAC (Microsoft Data Access Components). Even
though the interfaces exposed by the providers are common, each provider is
different in the sense they have specific optimizations relevant to the specific
data source you perform on data retrieval. OLE DB exposes the COM inter-
face and is written in unmanaged code (code that runs outside the .NET
Framework CLR). The .NET Framework provides you with a way of having in-
teroperability between managed and unmanaged code by which you can cre-
ate a .NET wrapper that uses the unmanaged code but provides the function-
ality of a managed provider. There is such a wrapper on top of the OLE DB
that is called the Unmanaged .NET Data Provider for the data sources that do
not have a native implementation of the .NET data provider.
The Microsoft OLE DB provider for SQL Server has been the primary way of
connecting to a Microsoft SQL Server to date. In the SQL Server 2005 re-
lease, this OLE DB provider has been repackaged and named SQL Native
Client. SQL Native Client provides easy manageability of upgrades to the
OLE DB provider. Analysis Services 2005 provides the capability of connect-
ing to any data source that provides the OLE DB interface, including the Ana-
lysis Server OLE DB provider by which you can retrieve data from another
Analysis Server.
The Trade-Offs
Analysis Services 2000 supported connection to data sources through OLE
DB providers only. Analysis Services 2005 has a much tighter integration with
the .NET Framework and supports connections via OLE DB providers and
.NET data providers. If you deployed the .NET Framework across your entire
organization, we recommend you use the .NET providers to access data from
relational data sources. You might encounter a certain amount of perform-
ance degradation by using the .NET provider; however, the uniformity, main-
tainability, inherent connection pooling capabilities, and security provided by
.NET data providers are worth the risk of taking the hit on performance. If you
Search WWH ::
Custom Search