Desembaraçar os novos drivers ODBC e OLEDB do Microsoft SQL Server
Alguns de vocês já devem saber que a Microsoft voltou atrás em sua descontinuação planejada do OLEDB e forneceu um novo driver OLEDB. No entanto, pode ser difícil descobrir o que você deve usar. Quando estávamos usando o SQL Server Native Client, era muito fácil - o Native Client tinha OLEDB e ODBC enviados em um único arquivo DLL, facilitando a instalação. Tudo o que você precisava para se certificar de que estava usando a versão correta do Native Client.
Com o SQL Server agora disponível no Linux, não faz mais sentido distribuir o Native Client, já que o Linux em geral não suporta OLEDB, que é principalmente uma tecnologia apenas para Windows usada principalmente por produtos da Microsoft. Por esse motivo, a Microsoft não optou por combinar ODBC e OLEDB em uma única DLL. Se seu aplicativo contiver código VBA que usa DAO e ADO, você precisará instalar dois diferentes provedores para obter o recurso e suporte mais recentes para ODBC e OLEDB, respectivamente.
A convenção de nomenclatura pode ser um pouco confusa porque muitas pessoas se referem vagamente a vários drivers simplesmente como “driver ODBC” ou “provedor OLEDB”. Então vamos esclarecer os nomes. Começaremos identificando as versões obsoletas e, em seguida, veremos as versões atuais.
Versões obsoletas
Por padrão, todas as versões do Windows vêm com duas bibliotecas de cliente de acesso a dados do SQL Server pré-instaladas:
Provedor Microsoft OLE DB para SQL Server (também conhecido como SQLOLEDB)
Driver ODBC do Microsoft SQL Server (também conhecido como SQLODBC)
É muito importante observar que eles estão OBSOLETO . Esses são voltados para o SQL Server 2000 e carecem de novos recursos introduzidos desde então. O Windows não enviar novos drivers ou atualizá-los por meio do Windows Update. Daqui para frente, você, o desenvolvedor do aplicativo, deve fornecer os drivers da versão apropriada para usar com seu aplicativo, em vez de depender dos fornecidos pelo Windows. Faça NÃO use-os em seu desenvolvimento atual.
Versões atuais
Com isso fora do caminho, vamos ver o driver ODBC correto e o provedor OLEDB que podemos querer usar.
Driver ODBC 17 para SQL Server
No momento da escrita, o Driver ODBC 17 para SQL Server é o driver mais recente e pode ser baixado no link fornecido. A string de conexão se parece com isso:
ODBC;DRIVER=ODBC Driver 17 for SQL Server;SERVER=myServer;DATABASE=myDatabase; Driver OLE DB 18 para SQL Server
No momento da escrita, o driver OLEDB 18 é o driver mais recente. Embora a versão seja uma versão superior, o conjunto de recursos é equivalente ao Driver ODBC 17 para SQL Server. A string de conexão se parece com isso:
Provider=MSOLEDBSQL;Server=myServer; Database=myDataBase; 32 bits ou 64 bits?
Uma pergunta comum que surge é se deve-se instalar as versões de 64 ou 32 bits do driver. A resposta é a mesma, independentemente de quais versões estamos discutindo e sempre depende do sistema operacional, não do Office. Portanto, se você estiver executando o Access de 32 bits no Windows de 64 bits, deverá instalar drivers de 64 bits. Isso incluirá os componentes de 32 bits necessários para que o acesso de 32 bits seja executado.
Posso usar o SQL Server Native Client?
Oficialmente, o SQL Server Native Client tem suporte até o SQL Server 2012. No entanto, você ainda pode usá-lo para se conectar a versões mais recentes do SQL Server. Existem vários recursos que estão faltando no Native Client. Com o passar do tempo, eles se tornarão cada vez mais inadequados para suas necessidades, especialmente com a tecnologia Azure. Embora você possa continuar a usá-lo para seus aplicativos existentes, recomendamos que você planeje novos desenvolvimentos usando os drivers ODBC e OLEDB separados e migre seus aplicativos existentes quando possível. Você deve migrar quando houver a necessidade de fazer uso de novas tecnologias que são suportadas apenas por esses drivers mais recentes (os exemplos incluem autenticação do Azure ou recurso Always Encrypted).
Preciso dos dois?
Somente se você usar DAO e ADO. De um modo geral, todos os formulários e relatórios e consultas do Access estão sempre usando o DAO. A única vez que você pode usar o ADO é no código VBA. Portanto, se você não usa ADO, pode se safar apenas com o driver ODBC e isso deve ser suficiente para sua necessidade. Isso significa que quando você normalmente vincula suas tabelas, você usaria um código semelhante ao seguinte:
Dim db As DAO.Database
Dim tdf As DAO.TableDef Definir db =CurrentDb
Definir tdf =db.CreateTableDef
tdf.Name =“MyRemoteTable”
tdf.SourceTableName =“dbo.MyRemoteTable”
tdf.Connect =“ODBC;DRIVER=ODBC Driver 17 for SQL Server;SERVER=myServer;DATABASE=myDatabase;”
db.TableDefs.Append
A sintaxe usada para tdf.Connect funciona para querydef de passagem ou mesmo para a propriedade Connect do método DAO.Workspace.OpenDatabase.
É legal abrir conexões ADO usando ODBC, mas a desvantagem é que você acaba passando por mais camadas porque estaria usando o provedor OLEDB para ODBC para se conectar com o driver ODBC 17 para SQL Server. Se você ainda preferir usar ODBC de qualquer maneira, poderá usar o seguinte código para usar ODBC em vez de OLEDB:
Dim con As ADODB.Connection Set con =New ADODB.Connection
con.ConnectionString =“DRIVER=ODBC Driver 17 for SQL Server;SERVER=myServer;DATABASE=myDatabase;”
con.Open
É melhor evitar a camada extra e usar o OLEDB diretamente. Você pode usar este código para obter o melhor desempenho com seu código ADO:
Dim con As ADODB.Connection Set con =New ADODB.Connection
con.ConnectionString =“Provider=MSOLEDBSQL;Server=myServer; Database=myDataBase;”
con.Open
Assim, a única vez que você realmente precisará e usará o novo driver OLEDB para SQL Server é quando tiver código ADO em seu aplicativo e desejar usar toda a capacidade do ADO, que precisa ser habilitada pelo driver OLEDB subjacente.
Referência Adicional
Roteiro para a Tecnologia de Acesso a Dados da Microsoft
