oledb vs. odbc

You may get some help here
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqlmag02/html/TheEvolutionofData-AccessTechnologies.asp

ODBC
In the most basic kind of database design, applications rely on only one database. In such a simple setup, an application developer can program directly against the database system's interfaces. Although this approach provides a quick and efficient way to access data, it often poses a big problem when a business expands and the developer must scale up the application. The one-database approach also means that each off-the-shelf application must have a different version to support each database. As businesses change, grow, and merge, applications must access multiple databases running on different platforms.

ODBC technology provides a common interface for accessing heterogeneous SQL databases. ODBC uses SQL as a standard for accessing data. Figure 1, page 30, shows a diagram of a standard ODBC architecture. This interface provides maximum interoperability: One application can access different SQL database management systems (DBMSs) through a common set of code. Thus, a developer can build and distribute a client/server application without targeting a specific DBMS.

The developer can add database drivers to link the application to the user's choice of DBMS. As Figure 1 shows, the driver manager provides the intermediate link between the application and the databases. The ODBC interface contains a set of functions that the drivers of each DBMS implement. When an application changes its DBMS, the developer simply replaces the old driver with the new DBMS's driver and the application can work as usual—without the need for code modifications

OLE DB
Over the years, ODBC has become the standard for client/server database access. ODBC provides a standards-based interface that requires SQL processing capabilities and is optimized for a SQL-based approach. However, what happens if you want to access data in a nonrelational data source that doesn't use SQL (e.g., Microsoft Exchange Server, which doesn't store data relationally)?

Enter OLE DB. OLE DB builds on ODBC and extends the technology to a component architecture that delivers higher-level data-access interfaces. This architecture provides consistent access to SQL, non-SQL, and unstructured data sources across the enterprise and the Internet. (In fact, for access to SQL-based data, OLE DB still uses ODBC because it's the most optimized architecture for working with SQL.) As Figure 5, page 32, shows, OLE DB consists of three components: the data consumer (e.g., an application); the data provider, which contains and exposes data; and the service component, which processes and transports data (e.g., query processors, cursor engines). OLE DB is one API that operates against SQL data sources and non-SQL data sources such as mail and directories

Populært sagt er ODBC den gamle langsomme teknologi, og OLE DB er noget hurtigere og smartere. Med ODBC kunne man dog ofte være lidt mere driver-uafhængig.
ODBC giver ofte problemer med webhoteller, da ODBC linket manuelt skal oprettes på serveren (hvilket som regel koster knaster hos din udbyder).

ettol>Har du fået svaret?

odegaard: Man kan da sagtens bruge ODBC uden at skulle have udbyderen til at oprette et "link".