Я читав довідкову статтю MS Excel про pivotcache та цікавився, що вони означають джерелами OLE DB та ODBC

... Вам слід використовувати властивість CommandText замість властивості SQL, яка зараз існує в основному для сумісності з більш ранніми версіями Microsoft Excel. Якщо ви використовуєте обидва властивості, значення властивості CommandText має перевагу.

Для джерел OLE DB властивість CommandType описує значення властивості CommandText.

Для джерел ODBC властивість CommandText функціонує точно так само, як і властивість SQL, а встановлення властивості призводить до оновлення даних ...

Я дуже ціную ваші короткі відповіді.

Як повідомляє ADO: ActiveX Data Objects , книга Джейсона Т. Роффа, опублікована O'Reilly Media в 2001 році (відмінна діаграма тут), він говорить саме те, що сказала MOZILLA.

(безпосередньо зі сторінки 7 цієї книги)

• ODBC забезпечує доступ лише до реляційних баз даних
• OLE DB надає наступні можливості
  • Доступ до даних незалежно від її формату чи місцезнаходження
  • Повний доступ до джерел даних ODBC та драйверів ODBC

Отже, здавалося б, що OLE DB взаємодіє з джерелами даних на базі SQL ТРУ драйверного рівня ODBC.

Я не на 100% впевнений, що це зображення правильне. Два з'єднання, в яких я не впевнений, є ADO.NET через ADO C-api та OLE DB через ODBC до джерела даних на базі SQL (оскільки в цій діаграмі автор не ставить доступ OLE DB через ODBC, що я вважаю є помилкою).

ODBC: - Тільки для реляційних баз даних (Sql Server, Oracle тощо)

OLE DB: - Як для реляційних, так і нереляційних баз даних. (Oracle, Sql-Server, Excel, необроблені файли тощо)

Ось моє розуміння (не авторитетне):

ODBC - це технологічно-агностичний відкритий стандарт, який підтримується більшістю постачальників програмного забезпечення. OLEDB - це специфічний для Microsoft API API з епохи COM (COM був компонентом і технологією сумісності раніше .NET)

У якийсь момент різні постачальники даних, що користуються інформацією (наприклад, Oracle тощо), готові бути сумісними зі споживачами даних Microsoft, розробили постачальників OLEDB для своїх продуктів, але здебільшого OLEDB залишається стандартом лише для Microsoft. Зараз більшість джерел даних Microsoft дозволяють отримувати доступ як до ODBC, так і до OLEDB, в основному для сумісності із застарілими споживачами даних ODBC. Крім того, для ODBC існує провайдер OLEDB (обгортка), який дозволяє використовувати OLEDB для доступу до джерел даних ODBC, якщо він цього бажає.

З точки зору особливостей OLEDB значно багатший за ODBC, але страждає від синдрому "один-до-правити-всі" (надмірно загальний, надскладний, не викликає сумнівів).

У світі, що не належить Microsoft, постачальники даних і клієнти, що базуються на ODBC, широко використовуються і нікуди не дістаються.

Всередині бульбашки Microsoft OLEDB припиняється на користь вроджених .NET API, які надбудовуються поверх того, що є рідним транспортним шаром для цього джерела даних (наприклад, TDS для MS SQL Server).

ODBC та OLE DB - це дві конкуруючі технології доступу до даних. Зокрема, що стосується SQL Server, Microsoft рекламувала їх обох як їх переважне майбутнє напрямок - хоча в різний час.

ODBC

ODBC - це загальновиробничий стандартний інтерфейс для доступу до даних, подібних до таблиці. Він був розроблений в основному для баз даних і представляє дані у колекціях записів, кожен з яких згрупований у колекцію полів. Кожне поле має свій власний тип даних, відповідний типу даних, які він містить. Кожен постачальник баз даних (Microsoft, Oracle, Postgres,…) постачає драйвер ODBC для своєї бази даних.

Існують також драйвери ODBC для об'єктів, які хоч і не є таблицями баз даних, але є досить подібними, що доступ до даних тим самим корисний. Прикладами є електронні таблиці, файли CSV та стовпчикові звіти.

OLE DB

OLE DB - це технологія Microsoft для доступу до даних. На відміну від ODBC, він охоплює як табличні, так і нетабличні дані, такі як повідомлення електронної пошти, веб-сторінки, документи Word та файлові каталоги. Однак він орієнтований на процедуру, а не на об'єктно-орієнтований і розглядається як досить складний інтерфейс, за допомогою якого можна розвивати доступ до джерел даних. Щоб подолати це, ADO був розроблений як об'єктно-орієнтований шар поверх OLE DB та для забезпечення більш простого і більш високого рівня - хоча і все ще дуже потужного - способу роботи з ним. Велика перевага ADO в тому, що ви можете використовувати його для маніпулювання властивостями, характерними для даного типу джерела даних, так само легко, як і ви можете використовувати його для доступу до тих властивостей, які застосовуються до всіх типів джерел даних. Ви не обмежені якось незадовільним найнижчим загальним знаменником.

Хоча всі бази даних мають драйвери ODBC, вони не мають усіх драйверів OLE DB. Однак існує інтерфейс між OLE та ODBC, який можна використовувати, якщо ви хочете отримати доступ до них у вигляді OLE DB-like. Цей інтерфейс називається MSDASQL (постачальник Microsoft OLE DB для ODBC).

Технології доступу до даних SQL Server

Оскільки SQL Server є (1) , зроблена Microsoft, і (2) платформа бази даних Microsoft, як ODBC і OLE DB є природним для нього.

ODBC

Оскільки всі інші платформи баз даних мали інтерфейси ODBC, Microsoft, очевидно, повинна була забезпечити її для SQL Server. На додаток до цього, DAO, оригінальна технологія за замовчуванням у Microsoft Access, використовує ODBC як стандартний спосіб спілкування з усіма зовнішніми джерелами даних. Це зробило інтерфейс ODBC обов'язковим умовою. Драйвер ODBC версії 6 для SQL Server, випущений із SQL Server 2000, все ще існує. Оновлені версії були випущені для обробки нових типів даних, технологій підключення, шифрування, HA / DR тощо, які з'явилися з наступними випусками. Станом на 07.07.2018 останній реліз - v13.1 «Драйвер ODBC для SQL Server», випущений 23.03.2018.

OLE DB

Це власна технологія Microsoft, яку вони активно просували приблизно з 2002 по 2005 роки, а також супровідний рівень ADO. Вони, очевидно, сподівалися, що це стане вибору технології доступу до даних. (Вони навіть зробили ADO методом за замовчуванням для доступу до даних у Access 2002/2003.) Однак, врешті-решт, стало очевидним, що це не відбудеться з ряду причин, таких як:

1. Світ не збирався перетворюватися на технології Microsoft і віддалятися від ODBC;
2. DAO / ODBC був швидшим, ніж ADO / OLE DB, а також був ретельно інтегрований у MS Access, тому не зміг померти природною смертю;
3. Нові технології, що розробляються Microsoft, зокрема ADO.NET, також можуть безпосередньо спілкуватися з ODBC. ADO.NET також міг би спілкуватися безпосередньо з OLE DB (таким чином, залишаючи ADO в затоці), але він не був (на відміну від ADO) виключно залежним від нього.

З цих причин та інших , Microsoft фактично застарів OLE DB як технологію доступу до даних для релізів SQL Server після v11 (SQL Server 2012). За кілька років до цього моменту вони виробляли та оновлювали Native Client SQL Server, який підтримував як ODBC, так і технології OLE DB. Однак наприкінці 2012 року вони оголосили, що будуть узгоджуватися з ODBC для нативного реляційного доступу до даних на SQL Server, і закликали всіх інших робити те саме. Вони також заявили, що версії SQL Server після v11 / SQL Server 2012 активно не підтримують OLE DB!

Це оголошення спровокувало бурю протесту. Люди втрачали розуміння того, чому МС раптом знецінила технологію, яку вони витратили протягом багатьох років, змусивши їх взяти на себе зобов’язання. Крім того, SSAS / SSRS і SSIS, які були написаними MS програмами, тісно пов'язаними з SQL Server, повністю або частково залежали від OLE DB. Ще одна скарга полягала в тому, що OLE DB має певні бажані функції, які, здавалося, неможливо перенести назад до ODBC - адже OLE DB мав багато хороших моментів.

У жовтні 2017 року Microsoft поступилася і офіційно не застаріла DB OLE . Вони оголосили про неминучий прихід нового драйвера (MSOLEDBSQL), який матиме наявний набір функцій Native Client 11, а також запроваджуватиме відключення підмережі та підтримку TLS 1.2. Водія звільнили у березні 2018 року.

На самому базовому рівні це просто різні API для різних джерел даних (тобто бази даних). OLE DB є новішим та, можливо, кращим.

Ви можете прочитати більше про обидва у Вікіпедії:

1. OLE DB
2. ODBC

Тобто ви могли підключитися до тієї ж бази даних за допомогою драйвера ODBC або драйвера OLE DB. Різниця в поведінці бази даних у цих випадках стосується вашої книги.

Обидва є постачальниками даних (API, який ваш код використовуватиме для розмови з джерелом даних). Представлений Oledb у 1998 році мав бути заміною ODBC (введений у 1992 р.)

• серпень, 2011 р. Microsoft застаріло OLE DB ( Microsoft узгоджується з ODBC для Native реляційного доступу до даних )

• жовтень 2017: Microsoft недооцінює OLE DB ( анонсує новий реліз драйвера OLE DB для SQL Server )

Я не впевнений у всіх подробицях, але я розумію, що OLE DB і ODBC - це два API, які доступні для підключення до різних типів баз даних, не маючи справу з усіма конкретними деталями реалізації кожної з них. Відповідно до статті Wikipedia про OLE DB , OLE DB є спадкоємцем Microsoft в ODBC і надає деякі функції, які ви, можливо, не зможете зробити з ODBC, наприклад, доступ до електронних таблиць як джерел бази даних.

На веб-сайті Microsoft видно, що рідний постачальник OLEDB застосовується безпосередньо до SQL-сервера, а інший постачальник OLEDB під назвою OLEDB Provider для ODBC для доступу до інших баз даних, таких як Sysbase, DB2 і т.д. Існують різні види компонентів у постачальника OLEDB. Додаткову інформацію див. У розділі Розподілені запити на MSDN .

ODBC працює лише для реляційних баз даних, він не може працювати з нереляційними базами даних, такими як файли Ms Excel. Де Олебд може все робити.

Щоб знати, чому M $ винаходить OLEDB, ви не можете порівнювати OLEDB з ODBC. Натомість слід порівнювати OLEDB з DAO, RDO або ADO. Останній багато в чому покладається на SQL. Однак OLEDB покладається на COM. Але ODBC вже існує багато років, тож є мости OLEDB-ODBC, щоб виправити це. Я думаю, що існує велика картина, коли M $ винаходить OLEDB.