Districare i nuovi driver ODBC e OLEDB di Microsoft SQL Server
Alcuni di voi potrebbero già sapere che Microsoft ha fatto marcia indietro sulla deprecazione pianificata di OLEDB e ha fornito un nuovo driver OLEDB. Tuttavia, può essere un grattacapo capire cosa dovresti usare. Quando utilizzavamo SQL Server Native Client, era piuttosto semplice:Native Client conteneva sia OLEDB che ODBC in un unico file DLL, semplificando l'installazione. Tutto quello che dovevi assicurarti di utilizzare la versione corretta di Native Client.
Con SQL Server ora disponibile su Linux, non ha più senso distribuire Native Client, poiché Linux in generale non supporta OLEDB, che è principalmente una tecnologia solo Windows utilizzata principalmente dai prodotti Microsoft. Per questo motivo, Microsoft non ha scelto di combinare ODBC e OLEDB in un'unica DLL. Se la tua applicazione contiene codice VBA che utilizza sia DAO che ADO, dovresti installarne due provider diversi per ottenere la funzionalità e il supporto più recenti rispettivamente per ODBC e OLEDB.
La convenzione di denominazione può creare un po' di confusione perché molte persone si riferiranno vagamente a vari driver semplicemente come "driver ODBC" o "provider OLEDB". Quindi chiariamo i nomi. Inizieremo con l'identificazione delle versioni obsolete e poi esamineremo le versioni correnti.
Versioni obsolete
Per impostazione predefinita, tutte le versioni di Windows sono dotate di due librerie client di accesso ai dati di SQL Server preinstallate:
Provider Microsoft OLE DB per SQL Server (noto anche come SQLOLEDB)
Driver ODBC per Microsoft SQL Server (noto anche come SQLODBC)
È molto importante notare che quelli sono DEPRECATI . Questi sono destinati a SQL Server 2000 e mancano di nuove funzionalità introdotte da allora. Windows non spedire eventuali nuovi driver o aggiornarli tramite il suo Windows Update. In futuro, tu, lo sviluppatore dell'applicazione, devi fornire i driver della versione appropriata da utilizzare con la tua applicazione, piuttosto che fare affidamento su quelli forniti da Windows. NON usa quelli nel tuo sviluppo attuale.
Versioni attuali
Detto questo, diamo un'occhiata al driver ODBC e al provider OLEDB corretti che potremmo voler utilizzare.
Driver ODBC 17 per SQL Server
Al momento della scrittura, il driver ODBC 17 per SQL Server è il driver più recente e può essere scaricato nel collegamento fornito. La stringa di connessione è simile alla seguente:
ODBC;DRIVER=ODBC Driver 17 for SQL Server;SERVER=myServer;DATABASE=myDatabase;
Driver OLE DB 18 per SQL Server
Al momento della scrittura, il driver OLEDB 18 è il driver più recente. Anche se la versione è una superiore, il set di funzionalità è equivalente al driver ODBC 17 per SQL Server. La stringa di connessione è simile a questa:
Provider=MSOLEDBSQL;Server=myServer; Database=myDataBase;
32 o 64 bit?
Una domanda comune che si pone è se si debbano installare le versioni a 64 o 32 bit del driver. La risposta è la stessa indipendentemente dalle versioni di cui stiamo discutendo e dipende sempre dal sistema operativo, non da Office. Pertanto, se si esegue l'accesso a 32 bit su Windows a 64 bit, si consiglia di installare i driver a 64 bit. Ciò includerà i componenti a 32 bit necessari per l'esecuzione di Access a 32 bit.
Posso utilizzare SQL Server Native Client?
Ufficialmente, SQL Server Native Client è supportato fino a SQL Server 2012. Tuttavia, puoi ancora usarlo per connetterti alle versioni più recenti di SQL Server. Ci sono diverse funzionalità che mancano in Native Client. Col passare del tempo, diventeranno sempre più inadatti alle tue esigenze, in particolare con la tecnologia Azure. Sebbene tu possa continuare a usarlo per le tue applicazioni esistenti, ti consigliamo di pianificare nuovi sviluppi utilizzando i driver ODBC e OLEDB separati e di migrare le tue applicazioni esistenti quando possibile. È necessario eseguire la migrazione quando è necessario utilizzare nuove tecnologie supportate solo dai driver più recenti (ad esempio, l'autenticazione di Azure o la funzionalità Always Encrypted).
Ho bisogno di entrambi?
Solo se usi sia DAO che ADO. In generale, tutti i moduli, i report e le query di accesso utilizzano sempre DAO. L'unica volta in cui potresti utilizzare ADO è all'interno del codice VBA. Quindi, se non usi ADO, puoi farla franca solo con il driver ODBC e questo dovrebbe essere sufficiente per le tue necessità. Ciò significa che quando colleghi normalmente le tue tabelle, utilizzeresti un codice simile al seguente:
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Imposta db =CurrentDb
Imposta tdf =db.CreateTableDef
tdf.Name =“MyRemoteTable”
tdf.SourceTableName =“dbo.MyRemoteTable”
tdf.Connect =“ODBC;DRIVER=Driver ODBC 17 per SQL Server;SERVER=myServer;DATABASE=myDatabase;”
db.TableDefs.Append
La sintassi utilizzata per tdf.Connect funziona per querydef pass-through o anche per la proprietà Connect del metodo DAO.Workspace.OpenDatabase.
È legale aprire connessioni ADO utilizzando ODBC, ma lo svantaggio è che si finisce per passare attraverso più livelli perché si utilizzerà il provider OLEDB per ODBC per connettersi con il driver ODBC 17 per SQL Server. Se preferisci comunque utilizzare ODBC, puoi utilizzare il codice seguente per utilizzare ODBC su OLEDB:
Dim con As ADODB.Connection
Set con =New ADODB.Connection
con.ConnectionString =“DRIVER=Driver ODBC 17 per SQL Server;SERVER=myServer;DATABASE=myDatabase;”
con.Open
È meglio evitare il livello aggiuntivo e utilizzare direttamente OLEDB. Puoi utilizzare questo codice per ottenere le migliori prestazioni con il tuo codice ADO:
Dim con As ADODB.Connection
Set con =New ADODB.Connection
con.ConnectionString =“Provider=MSOLEDBSQL;Server=myServer; Database=myDataBase;”
con.Open
Pertanto, l'unica volta in cui sarà effettivamente necessario e utilizzare il nuovo driver OLEDB per SQL Server è quando si dispone di codice ADO nell'applicazione e si desidera utilizzare tutte le funzionalità di ADO, che devono essere abilitate dal driver OLEDB sottostante.
Riferimento aggiuntivo
Roadmap per la tecnologia di accesso ai dati Microsoft
