Czytałem artykuł pomocy MS Excel o pivotcache i zastanawiałem się, co oznaczają źródła OLE DB i ODBC

... Należy użyć właściwości CommandText zamiast właściwości SQL, która obecnie istnieje głównie w celu zapewnienia zgodności z wcześniejszymi wersjami programu Microsoft Excel. Jeśli używasz obu właściwości, pierwszeństwo ma wartość właściwości CommandText.

W przypadku źródeł OLE DB właściwość CommandType opisuje wartość właściwości CommandText.

W przypadku źródeł ODBC właściwość CommandText działa dokładnie tak samo, jak właściwość SQL, a ustawienie właściwości powoduje odświeżenie danych ...

Naprawdę doceniam twoje krótkie odpowiedzi.

Według ADO: ActiveX Data Objects , książki Jasona T. Roffa, opublikowanej przez O'Reilly Media w 2001 roku (doskonały diagram tutaj), mówi dokładnie to, co powiedział MOZILLA.

(bezpośrednio ze strony 7 tej książki)

• ODBC zapewnia dostęp tylko do relacyjnych baz danych
• OLE DB zapewnia następujące funkcje
  • Dostęp do danych niezależnie od ich formatu czy lokalizacji
  • Pełny dostęp do źródeł danych ODBC i sterowników ODBC

Wydawałoby się więc, że OLE DB współdziała ze źródłami danych opartymi na SQL poprzez warstwę sterownika ODBC.

Nie jestem w 100% pewien, czy ten obraz jest poprawny. Dwa połączenia, których nie jestem pewien, to ADO.NET przez ADO C-api i OLE DB przez ODBC do źródła danych SQL (ponieważ na tym diagramie autor nie umieszcza dostępu OLE DB przez ODBC, co moim zdaniem jest błędem).

ODBC: - Tylko dla relacyjnych baz danych (Sql Server, Oracle itp.)

OLE DB: - dla relacyjnych i nierelacyjnych baz danych. (Oracle, Sql-Server, Excel, pliki RAW itp.)

Oto moje zrozumienie (nieautorytatywne):

ODBC to otwarty standard niezależny od technologii, obsługiwany przez większość dostawców oprogramowania. OLEDB to specyficzny dla technologii interfejs API firmy Microsoft z ery COM (COM był komponentem i technologią współdziałania przed .NET)

W pewnym momencie różni dostawcy danych (np. Oracle itp.), Chcąc być zgodni z konsumentami danych firmy Microsoft, opracowali dostawców OLEDB dla swoich produktów, ale w większości OLEDB pozostaje standardem wyłącznie dla firmy Microsoft. Obecnie większość źródeł danych firmy Microsoft umożliwia dostęp zarówno do ODBC, jak i OLEDB, głównie w celu zapewnienia zgodności ze starszymi odbiorcami danych ODBC. Istnieje również dostawca OLEDB (opakowanie) dla ODBC, który pozwala na użycie OLEDB w celu uzyskania dostępu do źródeł danych ODBC, jeśli sobie tego życzy.

Pod względem funkcji OLEDB jest znacznie bogatszy niż ODBC, ale cierpi na zespół jednego pierścienia, aby rządzić wszystkimi (zbyt ogólny, nadmiernie skomplikowany, nieoparty).

W świecie innym niż Microsoft dostawcy danych i klienci bazujący na ODBC są szeroko wykorzystywani i nigdzie nie idą.

Wewnątrz Microsoft bubble OLEDB jest wycofywany na rzecz natywnych interfejsów .NET API zbudowanych na podstawie natywnej warstwy transportowej dla tego źródła danych (np. TDS dla MS SQL Server).

ODBC i OLE DB to dwie konkurujące ze sobą technologie dostępu do danych. W szczególności w odniesieniu do SQL Server, Microsoft promował oba z nich jako preferowany kierunek przyszłości - choć w różnym czasie.

ODBC

ODBC to branżowy standardowy interfejs umożliwiający dostęp do danych tabelarycznych. Został opracowany przede wszystkim dla baz danych i prezentuje dane w zbiorach rekordów, z których każdy jest pogrupowany w zbiór pól. Każde pole ma swój własny typ danych, odpowiedni dla typu zawartych w nim danych. Każdy dostawca baz danych (Microsoft, Oracle, Postgres,…) dostarcza sterownik ODBC dla swojej bazy danych.

Istnieją również sterowniki ODBC dla obiektów, które choć nie są tabelami bazy danych, są na tyle podobne, że dostęp do danych w ten sam sposób jest przydatny. Przykładami są arkusze kalkulacyjne, pliki CSV i raporty kolumnowe.

OLE DB

OLE DB to technologia firmy Microsoft umożliwiająca dostęp do danych. W przeciwieństwie do ODBC obejmuje zarówno dane tabelaryczne, jak i inne niż tabelaryczne, takie jak wiadomości e-mail, strony internetowe, dokumenty programu Word i katalogi plików. Jest jednak zorientowany raczej na procedury niż obiektowo i jest uważany za dość trudny interfejs, za pomocą którego można rozwijać dostęp do źródeł danych. Aby temu zaradzić, ADO został zaprojektowany jako warstwa zorientowana obiektowo na wierzchu OLE DB i aby zapewnić prostszy i wyższy poziom - choć wciąż bardzo potężny - sposób pracy z nim. Ogromną zaletą ADO jest to, że można go używać do manipulowania właściwościami specyficznymi dla danego typu źródła danych, tak samo łatwo, jak można go używać do uzyskiwania dostępu do właściwości, które mają zastosowanie do wszystkich typów źródeł danych. Nie jesteś ograniczony do jakiegoś niezadowalającego najniższego wspólnego mianownika.

Chociaż wszystkie bazy danych mają sterowniki ODBC, nie wszystkie mają sterowniki OLE DB. Istnieje jednak interfejs między OLE i ODBC, którego można użyć, jeśli chcesz uzyskać do nich dostęp w sposób podobny do OLE DB. Ten interfejs nosi nazwę MSDASQL (dostawca Microsoft OLE DB dla ODBC).

Technologie dostępu do danych programu SQL Server

Ponieważ SQL Server jest (1) produkowany przez Microsoft i (2) jest platformą bazodanową Microsoft, zarówno ODBC, jak i OLE DB są dla niego naturalnym rozwiązaniem.

ODBC

Ponieważ wszystkie inne platformy bazodanowe miały interfejsy ODBC, Microsoft oczywiście musiał dostarczyć jeden dla SQL Server. Oprócz tego DAO, oryginalna domyślna technologia w programie Microsoft Access, używa ODBC jako standardowego sposobu komunikowania się ze wszystkimi zewnętrznymi źródłami danych. To sprawiło, że interfejs ODBC stał się warunkiem sine qua non. Sterownik ODBC w wersji 6 dla SQL Server, wydany wraz z SQL Server 2000, wciąż jest dostępny. Zostały wydane zaktualizowane wersje obsługujące nowe typy danych, technologie połączeń, szyfrowanie, HA / DR itp., Które pojawiły się w kolejnych wersjach. Od 09/07/2018 najnowszą wersją jest 13.1 „Sterownik ODBC dla SQL Server”, wydana 23.03.2018.

OLE DB

To własna technologia Microsoftu, którą intensywnie promował w latach 2002-2005 wraz z towarzyszącą jej warstwą ADO. Najwyraźniej mieli nadzieję, że stanie się to preferowaną technologią dostępu do danych. (Uczynili nawet ADO domyślną metodą uzyskiwania dostępu do danych w programie Access 2002/2003). Ostatecznie jednak okazało się, że nie stanie się to z wielu powodów, takich jak:

1. Świat nie zamierzał przejść na technologie Microsoft i odejść od ODBC;
2. DAO / ODBC był szybszy niż ADO / OLE DB i był również całkowicie zintegrowany z MS Access, więc nie umarł śmiercią naturalną;
3. Nowe technologie opracowywane przez Microsoft, w szczególności ADO.NET, mogą również komunikować się bezpośrednio z ODBC. ADO.NET mógł również rozmawiać bezpośrednio z OLE DB (pozostawiając ADO w zaścianku), ale nie był (w przeciwieństwie do ADO) wyłącznie od niego zależny.

Z tych i innych powodów firma Microsoft faktycznie wycofała OLE DB jako technologię dostępu do danych dla wersji SQL Server po wersji v11 (SQL Server 2012). Przez kilka lat wcześniej tworzyli i aktualizowali SQL Server Native Client, który obsługiwał zarówno technologie ODBC, jak i OLE DB. Jednak pod koniec 2012 roku ogłosili, że będą dostosowywać się do ODBC w celu uzyskania natywnego dostępu do danych relacyjnych w SQL Server i zachęcali wszystkich do zrobienia tego samego. Ponadto stwierdził, że ich wersje SQL Server po v11 / SQL Server 2012 będzie aktywnie nie obsługują OLE DB!

To ogłoszenie wywołało burzę protestów. Ludzie nie mogli zrozumieć, dlaczego stwardnienie rozsiane nagle zaczęło deprecjonować technologię, na którą musieli się zaangażować przez lata. Ponadto SSAS / SSRS i SSIS, które były aplikacjami napisanymi przez MS, ściśle powiązanymi z SQL Server, były całkowicie lub częściowo zależne od OLE DB. Kolejnym zarzutem było to, że OLE DB miał pewne pożądane funkcje, których przeniesienie z powrotem do ODBC wydawało się niemożliwe - w końcu OLE DB miał wiele zalet.

W październiku 2017 roku Microsoft ustąpił i oficjalnie wycofał OLE DB . Ogłosili rychłe nadejście nowego sterownika (MSOLEDBSQL), który będzie miał istniejący zestaw funkcji klienta natywnego 11, a także wprowadzi przełączanie awaryjne wielu podsieci i obsługę protokołu TLS 1.2. Sterownik został wydany w marcu 2018 roku.

Na bardzo podstawowym poziomie są to po prostu różne API dla różnych źródeł danych (tj. Baz danych). OLE DB jest nowszy i prawdopodobnie lepszy.

Możesz przeczytać więcej na temat obu w Wikipedii:

1. OLE DB
2. ODBC

Oznacza to, że można połączyć się z tą samą bazą danych za pomocą sterownika ODBC lub sterownika OLE DB. Różnica w zachowaniu bazy danych w tych przypadkach jest tym, do czego odnosi się twoja książka.

Obaj są dostawcami danych (API, którego Twój kod będzie używać do komunikacji ze źródłem danych). Oledb, który został wprowadzony w 1998 roku, miał zastąpić ODBC (wprowadzony w 1992)

• Sierpień 2011: Microsoft wycofuje OLE DB ( Microsoft dostosowuje się do ODBC dla natywnego relacyjnego dostępu do danych )

• Październik 2017: Microsoft wycofuje OLE DB ( zapowiedź nowej wersji sterownika OLE DB dla SQL Server )

Nie jestem pewien wszystkich szczegółów, ale rozumiem, że OLE DB i ODBC to dwa interfejsy API, które są dostępne do łączenia się z różnymi typami baz danych bez konieczności zajmowania się wszystkimi szczegółami dotyczącymi implementacji każdego z nich. Zgodnie z artykułem Wikipedii na temat OLE DB , OLE DB jest następcą ODBC firmy Microsoft i zapewnia pewne funkcje, których możesz nie być w stanie wykonać z ODBC, takie jak dostęp do arkuszy kalkulacyjnych jako źródeł baz danych.

Na stronie firmy Microsoft widać, że natywny dostawca OLEDB jest stosowany bezpośrednio do serwera SQL, a inny dostawca OLEDB o nazwie OLEDB Provider dla ODBC w celu uzyskania dostępu do innych baz danych, takich jak Sysbase, DB2 itp. W ramach dostawcy OLEDB istnieją różne rodzaje komponentów. Aby uzyskać więcej informacji, zobacz Zapytania rozproszone w witrynie MSDN .

ODBC działa tylko w przypadku relacyjnych baz danych, nie może działać z nierelacyjnymi bazami danych, takimi jak pliki Ms Excel. Gdzie Olebd może zrobić wszystko.

Aby wiedzieć, dlaczego M $ wymyśla OLEDB, nie można porównać OLEDB z ODBC. Zamiast tego powinieneś porównać OLEDB z DAO, RDO lub ADO. Ten ostatni w dużej mierze opiera się na języku SQL. Jednak OLEDB polega na COM. Ale ODBC istnieje już od wielu lat, więc istnieją mosty OLEDB-ODBC, aby temu zaradzić. Myślę, że kiedy M $ wymyśla OLEDB, jest duży obraz.