Stavo leggendo un articolo di aiuto di MS Excel su pivotcache e mi chiedevo cosa significassero per le fonti OLE DB e ODBC

... È necessario utilizzare la proprietà CommandText anziché la proprietà SQL, che ora esiste principalmente per la compatibilità con le versioni precedenti di Microsoft Excel. Se si utilizzano entrambe le proprietà, il valore della proprietà CommandText ha la precedenza.

Per le origini OLE DB , la proprietà CommandType descrive il valore della proprietà CommandText.

Per le origini ODBC , la proprietà CommandText funziona esattamente come la proprietà SQL e l'impostazione della proprietà provoca l'aggiornamento dei dati ...

Apprezzo molto le tue brevi risposte.

Secondo ADO: ActiveX Data Objects , un libro di Jason T. Roff, pubblicato da O'Reilly Media nel 2001 (diagramma eccellente qui), dice esattamente ciò che MOZILLA ha detto.

(direttamente dalla pagina 7 di quel libro)

• ODBC fornisce l'accesso solo ai database relazionali
• OLE DB offre le seguenti funzionalità
  • Accesso ai dati indipendentemente dal loro formato o posizione
  • Accesso completo alle origini dati ODBC e ai driver ODBC

Quindi sembra che OLE DB interagisca con le origini dati basate su SQL THRU il livello del driver ODBC.

Non sono sicuro al 100% che questa immagine sia corretta. Le due connessioni di cui non sono sicuro sono ADO.NET tramite ADO C-api e OLE DB tramite ODBC a origine dati basata su SQL (perché in questo diagramma l'autore non inserisce l'accesso OLE DB tramite ODBC, che credo è un errore).

ODBC: - Solo per database relazionali (Sql Server, Oracle ecc.)

OLE DB: - Per database sia relazionali che non relazionali. (Oracle, SQL Server, Excel, file non elaborati, ecc.)

Ecco la mia comprensione (non autorevole):

ODBC è uno standard aperto indipendente dalla tecnologia supportato dalla maggior parte dei produttori di software. OLEDB è un'API Microsoft specifica per la tecnologia dell'era COM (COM era un componente e una tecnologia di interoperabilità prima di .NET)

Ad un certo punto, vari fornitori di dati (ad es. Oracle ecc.), Disposti a essere compatibili con i consumatori di dati Microsoft, hanno sviluppato provider OLEDB per i loro prodotti, ma per lo più OLEDB rimane uno standard solo per Microsoft. Ora, la maggior parte delle fonti di dati Microsoft consente l'accesso ODBC e OLEDB, principalmente per la compatibilità con i consumatori di dati ODBC legacy. Inoltre, esiste un provider OLEDB (wrapper) per ODBC che consente di utilizzare OLEDB per accedere alle origini dati ODBC se lo si desidera.

In termini di funzionalità, OLEDB è sostanzialmente più ricco di ODBC ma soffre di una sindrome da un solo squillo (tutto troppo generico, troppo complicato, non supponente).

Nel mondo non Microsoft i provider di dati e i client basati su ODBC sono ampiamente utilizzati e non vanno da nessuna parte.

All'interno della bolla Microsoft, OLEDB viene gradualmente eliminato a favore delle API .NET native basate su qualunque sia il livello di trasporto nativo per tale origine dati (ad esempio TDS per MS SQL Server).

ODBC e OLE DB sono due tecnologie di accesso ai dati concorrenti. In particolare per quanto riguarda SQL Server, Microsoft ha promosso entrambi come direzione futura preferita, anche se in momenti diversi.

ODBC

ODBC è un'interfaccia standard a livello di settore per l'accesso a dati simili a tabelle. È stato sviluppato principalmente per database e presenta i dati in raccolte di record, ognuna delle quali è raggruppata in una raccolta di campi. Ogni campo ha il proprio tipo di dati adatto al tipo di dati che contiene. Ogni fornitore di database (Microsoft, Oracle, Postgres, ...) fornisce un driver ODBC per il proprio database.

Esistono anche driver ODBC per oggetti che, sebbene non siano tabelle di database, sono sufficientemente simili da consentire l'accesso ai dati nello stesso modo. Esempi sono fogli di calcolo, file CSV e rapporti colonnari.

OLE DB

OLE DB è una tecnologia Microsoft per l'accesso ai dati. A differenza di ODBC, comprende sia dati di tipo tabella che non di tipo tabella come messaggi di posta elettronica, pagine Web, documenti Word e directory di file. Tuttavia, è orientato alle procedure piuttosto che agli oggetti ed è considerato come un'interfaccia piuttosto difficile con cui sviluppare l'accesso alle fonti di dati. Per ovviare a questo, ADO è stato progettato per essere un livello orientato agli oggetti sopra OLE DB e per fornire un modo più semplice e di livello superiore - sebbene ancora molto potente - di lavorare con esso. Il grande vantaggio di ADO è che puoi usarlo per manipolare proprietà specifiche di un determinato tipo di origine dati, con la stessa facilità con cui puoi utilizzarlo per accedere a quelle proprietà che si applicano a tutti i tipi di origine dati. Non sei limitato a qualche minimo comune denominatore insoddisfacente.

Sebbene tutti i database dispongano di driver ODBC, non tutti dispongono di driver OLE DB. Esiste tuttavia un'interfaccia disponibile tra OLE e ODBC che può essere utilizzata se si desidera accedervi in ​​modo simile a OLE DB. Questa interfaccia è denominata MSDASQL (provider Microsoft OLE DB per ODBC).

Tecnologie di accesso ai dati di SQL Server

Poiché SQL Server è (1) creato da Microsoft e (2) la piattaforma di database Microsoft, sia ODBC che OLE DB si adattano perfettamente.

ODBC

Poiché tutte le altre piattaforme di database avevano interfacce ODBC, Microsoft ovviamente doveva fornirne una per SQL Server. Inoltre, DAO, la tecnologia predefinita originale in Microsoft Access, utilizza ODBC come metodo standard per comunicare con tutte le origini dati esterne. Ciò ha reso un'interfaccia ODBC un presupposto indispensabile. Il driver ODBC versione 6 per SQL Server, rilasciato con SQL Server 2000, è ancora disponibile. Versioni aggiornate sono state rilasciate per gestire i nuovi tipi di dati, tecnologie di connessione, crittografia, HA / DR ecc. Che sono apparsi con le versioni successive. Dal 09/07/2018 la versione più recente è la v13.1 "Driver ODBC per SQL Server", rilasciata il 23/03/2018.

OLE DB

Questa è la tecnologia di Microsoft, che stavano promuovendo fortemente tra il 2002 e il 2005, insieme al relativo livello ADO. Evidentemente speravano che sarebbe diventata la tecnologia di accesso ai dati preferita. (Hanno persino reso ADO il metodo predefinito per l'accesso ai dati in Access 2002/2003.) Tuttavia, alla fine è diventato evidente che ciò non sarebbe accaduto per una serie di motivi, come:

1. Il mondo non si sarebbe convertito in tecnologie Microsoft e lontano da ODBC;
2. DAO / ODBC era più veloce di ADO / OLE DB ed era anche completamente integrato in MS Access, quindi non sarebbe morto per morte naturale;
3. Le nuove tecnologie che venivano sviluppate da Microsoft, in particolare ADO.NET, potevano anche parlare direttamente con ODBC. ADO.NET poteva anche parlare direttamente con OLE DB (lasciando così ADO in un arretrato), ma non era (diversamente da ADO) solo dipendente da esso.

Per questi e altri motivi , Microsoft ha deprecato OLE DB come tecnologia di accesso ai dati per le versioni di SQL Server dopo la v11 (SQL Server 2012). Per un paio d'anni prima di questo punto, avevano prodotto e aggiornato SQL Server Native Client, che supportava entrambe le tecnologie ODBC e OLE DB. Alla fine del 2012, tuttavia, hanno annunciato che si sarebbero allineati con ODBC per l'accesso nativo ai dati relazionali in SQL Server e hanno incoraggiato tutti gli altri a fare lo stesso. Hanno inoltre dichiarato che rilascia SQL Server dopo v11 / SQL Server 2012 sarebbe attivamente non supporta OLE DB!

Questo annuncio ha provocato una tempesta di proteste. La gente non riusciva a capire perché improvvisamente la SM stava deprecando una tecnologia per la quale aveva impiegato anni a convincerlo. Inoltre, SSAS / SSRS e SSIS, che erano applicazioni scritte da MS intimamente collegate a SQL Server, dipendevano totalmente o parzialmente da OLE DB. Ancora un'altra lamentela è che OLE DB aveva alcune caratteristiche desiderabili che sembrava impossibile riportare su ODBC - dopotutto, OLE DB aveva molti buoni punti.

Nell'ottobre 2017, Microsoft ha ceduto e ufficialmente non deprecato OLE DB . Hanno annunciato l'arrivo imminente di un nuovo driver (MSOLEDBSQL) che avrebbe il set di funzionalità esistente di Native Client 11 e introdurrebbe anche il failover multi-subnet e il supporto TLS 1.2. Il driver è stato rilasciato nel marzo 2018.

A un livello molto elementare, si tratta di API diverse per le diverse origini dati (ad es. Database). OLE DB è più recente e probabilmente migliore.

Puoi leggere di più su entrambi in Wikipedia:

1. OLE DB
2. ODBC

Vale a dire che è possibile connettersi allo stesso database utilizzando un driver ODBC o un driver OLE DB. La differenza nel comportamento del database in questi casi è ciò a cui fa riferimento il tuo libro.

Entrambi sono fornitori di dati (API che il codice utilizzerà per comunicare con un'origine dati). Oledb, introdotto nel 1998, doveva essere un sostituto di ODBC (introdotto nel 1992)

• Agosto 2011: Microsoft depreca OLE DB ( Microsoft si allinea con ODBC per l'accesso ai dati relazionali nativi )

• Ottobre 2017: Microsoft non specifica OLE DB ( Annuncio della nuova versione del driver OLE DB per SQL Server )

Non sono sicuro di tutti i dettagli, ma la mia comprensione è che OLE DB e ODBC sono due API disponibili per la connessione a vari tipi di database senza dover gestire tutti i dettagli specifici dell'implementazione di ciascuno. Secondo l'articolo di Wikipedia su OLE DB , OLE DB è il successore di Microsoft a ODBC e fornisce alcune funzionalità che potresti non essere in grado di fare con ODBC, come l'accesso ai fogli di calcolo come origini del database.

Sul sito Web Microsoft, mostra che il provider OLEDB nativo viene applicato direttamente al server SQL e un altro provider OLEDB chiamato provider OLEDB per ODBC per accedere ad altri database, come Sysbase, DB2 ecc. Esistono diversi tipi di componenti nel provider OLEDB. Vedi Query distribuite su MSDN per ulteriori informazioni.

ODBC funziona solo per database relazionali, non può funzionare con database non relazionali come i file Ms Excel. Dove Olebd può fare tutto.

Per sapere perché M $ inventa OLEDB, non puoi confrontare OLEDB con ODBC. Invece, dovresti confrontare OLEDB con DAO, RDO o ADO. Quest'ultimo si basa in gran parte su SQL. Tuttavia, OLEDB si basa su COM. Ma ODBC è già lì da molti anni, quindi c'è un ponte OLEDB-ODBC per rimediare. Penso che ci sia un quadro generale quando M $ inventa OLEDB.