Estaba leyendo un artículo de ayuda de MS Excel sobre pivotcache y me pregunto qué quieren decir con fuentes OLE DB y ODBC
... Debe usar la propiedad CommandText en lugar de la propiedad SQL, que ahora existe principalmente para la compatibilidad con versiones anteriores de Microsoft Excel. Si usa ambas propiedades, el valor de la propiedad CommandText tiene prioridad.
Para las fuentes OLE DB , la propiedad CommandType describe el valor de la propiedad CommandText.
Para las fuentes ODBC , la propiedad CommandText funciona exactamente como la propiedad SQL, y establecer la propiedad hace que los datos se actualicen ...
Realmente aprecio tus respuestas cortas.
Respuestas:
Según ADO: ActiveX Data Objects , un libro de Jason T. Roff, publicado por O'Reilly Media en 2001 (excelente diagrama aquí), dice exactamente lo que dijo MOZILLA.
(directamente de la página 7 de ese libro)
Parece que OLE DB interactúa con fuentes de datos basadas en SQL a través de la capa de controlador ODBC.
No estoy 100% seguro de que esta imagen sea correcta. Las dos conexiones de las que no estoy seguro son ADO.NET a través de ADO C-api y OLE DB a través de ODBC a una fuente de datos basada en SQL (porque en este diagrama el autor no pone el acceso de OLE DB a través de ODBC, lo cual creo es un error).
fuente
System.Data.SqlClient
maneja el protocolo TDS en código administrado, solo usando código nativo para manejar la transmisión TCP / Named Pipes / etc a través de la red. Para las bases de datos que no tienen un proveedor administrado propio, puede usarSystem.Data.OleDb
para ajustar OLE DB oSystem.Data.Odbc
para ajustar ODBC, pero no se recomienda.ODBC: - Solo para bases de datos relacionales (Sql Server, Oracle, etc.)
OLE DB: - Para bases de datos relacionales y no relacionales. (Oracle, SQL Server, Excel, archivos sin formato, etc.)
fuente
Open Database Connectivity (ODBC) is Microsoft's strategic interface for accessing data in a heterogeneous environment of relational and non- relational database management systems.
support.microsoft.com/en-us/kb/110093Aquí está mi comprensión (no autorizada):
ODBC es un estándar abierto independiente de la tecnología compatible con la mayoría de los proveedores de software. OLEDB es una API de Microsoft específica de la tecnología de la era COM (COM era una tecnología de componentes e interoperabilidad antes de .NET)
En algún momento, varios proveedores de bases de datos (por ejemplo, Oracle, etc.), dispuestos a ser compatibles con los consumidores de datos de Microsoft, desarrollaron proveedores OLEDB para sus productos, pero en su mayor parte OLEDB sigue siendo un estándar exclusivo de Microsoft. Ahora, la mayoría de las fuentes de datos de Microsoft permiten el acceso tanto a ODBC como a OLEDB, principalmente por compatibilidad con los consumidores de datos heredados de ODBC. Además, existe un proveedor OLEDB (contenedor) para ODBC que le permite a uno usar OLEDB para acceder a las fuentes de datos ODBC si así lo desea.
En términos de las características, OLEDB es sustancialmente más rico que ODBC pero sufre del síndrome de un anillo para gobernarlos a todos (demasiado genérico, demasiado complicado, no es obstinado).
En el mundo que no es de Microsoft, los proveedores y clientes de datos basados en ODBC son ampliamente utilizados y no van a ninguna parte.
Dentro de la burbuja de Microsoft, OLEDB se está eliminando gradualmente a favor de las API nativas de .NET construidas sobre cualquier capa de transporte nativa para esa fuente de datos (por ejemplo, TDS para MS SQL Server).
fuente
ODBC y OLE DB son dos tecnologías de acceso a datos competidoras. Específicamente con respecto a SQL Server, Microsoft los ha promocionado a ambos como su Dirección Futura Preferida, aunque en diferentes momentos.
ODBC
ODBC es una interfaz estándar de toda la industria para acceder a datos similares a tablas. Fue desarrollado principalmente para bases de datos y presenta datos en colecciones de registros, cada uno de los cuales se agrupa en una colección de campos. Cada campo tiene su propio tipo de datos adecuado para el tipo de datos que contiene. Cada proveedor de base de datos (Microsoft, Oracle, Postgres, ...) proporciona un controlador ODBC para su base de datos.
También hay controladores ODBC para objetos que, aunque no son tablas de base de datos, son lo suficientemente similares como para acceder a los datos de la misma manera. Ejemplos son hojas de cálculo, archivos CSV e informes en columnas.
OLE DB
OLE DB es una tecnología de Microsoft para el acceso a datos. A diferencia de ODBC, abarca datos con y sin formato de tabla, como mensajes de correo electrónico, páginas web, documentos de Word y directorios de archivos. Sin embargo, está orientado a procedimientos más que a objetos y se considera una interfaz bastante difícil para desarrollar el acceso a las fuentes de datos. Para superar esto, ADO fue diseñado para ser una capa orientada a objetos sobre OLE DB y para proporcionar una forma más simple y de alto nivel, aunque aún muy poderosa, de trabajar con ella. La gran ventaja de ADO es que puede usarlo para manipular propiedades que son específicas de un tipo determinado de fuente de datos, tan fácilmente como puede usarlo para acceder a esas propiedades que se aplican a todos los tipos de fuentes de datos. No está restringido a algún mínimo común denominador insatisfactorio.
Si bien todas las bases de datos tienen controladores ODBC, no todas tienen controladores OLE DB. Sin embargo, hay una interfaz disponible entre OLE y ODBC que se puede utilizar si desea acceder a ellas de forma similar a OLE DB. Esta interfaz se llama MSDASQL (proveedor Microsoft OLE DB para ODBC).
Tecnologías de acceso a datos de SQL Server
Dado que SQL Server es (1) creado por Microsoft y (2) la plataforma de base de datos de Microsoft, tanto ODBC como OLE DB son ideales para ello.
ODBC
Como todas las demás plataformas de bases de datos tenían interfaces ODBC, Microsoft obviamente tenía que proporcionar una para SQL Server. Además de esto, DAO, la tecnología predeterminada original en Microsoft Access, utiliza ODBC como la forma estándar de hablar con todas las fuentes de datos externas. Esto hizo que una interfaz ODBC fuera una condición sine qua non. El controlador ODBC de la versión 6 para SQL Server, lanzado con SQL Server 2000, todavía está disponible. Se han lanzado versiones actualizadas para manejar los nuevos tipos de datos, tecnologías de conexión, cifrado, HA / DR, etc. que han aparecido con versiones posteriores. A partir del 07/09/2018, la versión más reciente es v13.1 "Controlador ODBC para SQL Server", lanzado el 23/03/2018.
OLE DB
Esta es la tecnología propia de Microsoft, que estaban promoviendo fuertemente desde aproximadamente 2002 - 2005, junto con su capa ADO. Evidentemente, esperaban que se convirtiera en la tecnología de acceso a datos de elección. (Incluso hicieron de ADO el método predeterminado para acceder a los datos en Access 2002/2003.) Sin embargo, eventualmente se hizo evidente que esto no iba a suceder por varias razones, tales como:
Por estas y otras razones , Microsoft desaprobó OLE DB como tecnología de acceso a datos para las versiones de SQL Server después de v11 (SQL Server 2012). Durante un par de años antes de este punto, habían estado produciendo y actualizando el SQL Server Native Client, que era compatible con las tecnologías ODBC y OLE DB. Sin embargo, a fines de 2012 anunciaron que se alinearían con ODBC para el acceso de datos relacionales nativos en SQL Server, y alentaron a todos los demás a hacer lo mismo. Afirmaron además que las versiones de SQL Server después de v11 / SQL Server 2012 no admitirían activamente OLE DB.
Este anuncio provocó una tormenta de protestas. Las personas no sabían por qué la EM de repente estaba desaprobando una tecnología con la que habían pasado años haciendo que se comprometieran. Además, SSAS / SSRS y SSIS, que eran aplicaciones escritas en MS íntimamente vinculadas a SQL Server, dependían total o parcialmente de OLE DB. Otra queja más fue que OLE DB tenía ciertas características deseables que parecía imposible trasladar a ODBC; después de todo, OLE DB tenía muchos puntos positivos.
En octubre de 2017, Microsoft cedió y oficialmente dejó de usar OLE DB . Anunciaron la inminente llegada de un nuevo controlador (MSOLEDBSQL) que tendría el conjunto de características existente del Native Client 11 y también introduciría la conmutación por error de múltiples subredes y el soporte TLS 1.2. El controlador fue lanzado en marzo de 2018.
fuente
En un nivel muy básico, esas son solo API diferentes para las diferentes fuentes de datos (es decir, bases de datos). OLE DB es más nuevo y posiblemente mejor.
Puedes leer más sobre ambos en Wikipedia:
Es decir, puede conectarse a la misma base de datos utilizando un controlador ODBC o un controlador OLE DB. La diferencia en el comportamiento de la base de datos en esos casos es a qué se refiere su libro.
fuente
Ambos son proveedores de datos (API que usará su código para hablar con una fuente de datos). Oledb, que se introdujo en 1998, estaba destinado a ser un reemplazo de ODBC (introducido en 1992)
fuente
• Agosto de 2011: Microsoft desprecia OLE DB ( Microsoft se está alineando con ODBC para el acceso a datos relacionales nativos )
• Octubre de 2017: Microsoft desprecia a OLE DB ( anunciando la nueva versión del controlador OLE DB para SQL Server )
fuente
No estoy seguro de todos los detalles, pero entiendo que OLE DB y ODBC son dos API que están disponibles para conectarse a varios tipos de bases de datos sin tener que lidiar con todos los detalles específicos de implementación de cada uno. De acuerdo con el artículo de Wikipedia sobre OLE DB , OLE DB es el sucesor de ODBC de Microsoft y proporciona algunas características que es posible que no pueda hacer con ODBC, como acceder a hojas de cálculo como fuentes de bases de datos.
fuente
En el sitio web de Microsoft, muestra que el proveedor OLEDB nativo se aplica al servidor SQL directamente y otro proveedor OLEDB llamado OLEDB Provider para que ODBC acceda a otra Base de Datos, como Sysbase, DB2, etc. Hay diferentes tipos de componentes bajo OLEDB Provider. Consulte Consultas distribuidas en MSDN para obtener más información.
fuente
ODBC funciona solo para bases de datos relacionales, no puede funcionar con bases de datos no relacionales como los archivos Ms Excel. Donde Olebd puede hacer todo.
fuente
Para saber por qué M $ inventa OLEDB, no se puede comparar OLEDB con ODBC. En su lugar, debe comparar OLEDB con DAO, RDO o ADO. Este último se basa en gran medida en SQL. Sin embargo, OLEDB se basa en COM. Pero ODBC ya está allí muchos años, por lo que hay puentes OLEDB-ODBC para remediar esto. Creo que hay una gran imagen cuando M $ inventa OLEDB.
fuente