Algunos de ustedes ya saben que Microsoft retrocedió en su desaprobación planificada de OLEDB y proporcionó un nuevo controlador OLEDB. Sin embargo, puede ser un dolor de cabeza calcular lo que debería estar usando. Cuando estábamos usando SQL Server Native Client, fue bastante fácil: el Native Client tenía OLEDB y ODBC enviados en un solo archivo DLL, lo que facilita la instalación. Todo lo que tenía que hacer para asegurarse de estar usando la versión correcta de Native Client.

Con SQL Server ahora disponible en Linux, ya no tiene sentido distribuir Native Client, ya que Linux en general no es compatible con OLEDB, que es principalmente una tecnología exclusiva de Windows utilizada principalmente por productos de Microsoft. Por esa razón, Microsoft no ha optado por combinar ODBC y OLEDB en una sola DLL. Si su aplicación contiene código VBA que usa DAO y ADO, entonces necesitará instalar dos proveedores diferentes para obtener la última característica y soporte para ODBC y OLEDB respectivamente.

La convención de nomenclatura puede ser un poco confusa porque muchas personas se refieren libremente a varios controladores como simplemente «controlador ODBC» o «proveedor OLEDB». Así que vamos a aclarar los nombres. Comenzaremos identificando las versiones obsoletas y luego veremos las versiones actuales.

Versiones obsoletas

Por defecto, todas las versiones de Windows vienen con dos bibliotecas de cliente de accesso a datos de SQL Server preinstaladas:

Proveedor Microsoft OLE DB para SQL Server (también conocido como SQLOLEDB)
Controlador ODBC de Microsoft SQL Server (también conocido como SQLODBC)

Es muy importante tener en cuenta que estos están DEPRECIADOS. Están dirigidos a SQL Server 2000 y carecen de nuevas características introducidas desde entonces. Windows no enviará ningún controlador nuevo ni los actualizará a través de su Actualización de Windows. En el futuro, usted, el desarrollador de la aplicación, debe proporcionar los controladores de la versión adecuada para usar con su aplicación, en lugar de depender de los proporcionados por Windows. NO los use en su desarrollo actual.

Versiones actuales

Veamos el controlador ODBC y el proveedor OLEDB correctos que queremos usar.

Controlador ODBC 17 para SQL Server

Al momento de escribir (Post original), el controlador ODBC 17 para SQL Server es el último controlador y se puede descargar en el enlace provisto. La cadena de conexión se ve así:

ODBC;DRIVER=ODBC Driver 17 for SQL Server;SERVER=myServer;DATABASE=myDatabase;

OLE DB Driver 18 para SQL Server

Al momento de escribir (Post original), el controlador OLEDB 18 es el último controlador. Aunque la versión es una superior, el conjunto de características es equivalente al ODBC Driver 17 para SQL Server. La cadena de conexión se ve así:

Provider=MSOLEDBSQL;Server=myServer; Database=myDataBase;

32 bits o 64 bits?

Una pregunta común que surge es si uno debe instalar las versiones de 64 bits o 32 bits del controlador. La respuesta es la misma independientemente de las versiones que estamos discutiendo y siempre depende del sistema operativo, no de Office. Por lo tanto, si está ejecutando Access de 32 bits en Windows de 64 bits, querrá instalar controladores de 64 bits. Esto incluirá los componentes de 32 bits necesarios para que se ejecute el Access de 32 bits.

¿Puedo usar SQL Server Native Client?

Oficialmente, SQL Server Native Client es compatible hasta SQL Server 2012. Sin embargo, aún puede usarlo para conectarse a versiones más recientes de SQL Server. Hay varias características que faltan en Native Client. A medida que pase el tiempo, se volverán cada vez más inadecuados para sus necesidades, especialmente con la tecnología Azure. Aunque es posible que pueda continuar usándolo para sus aplicaciones existentes, le recomendamos que planifique nuevos desarrollos utilizando los controladores ODBC y OLEDB separados y migre sus aplicaciones existentes cuando sea posible. Debe migrar cuando sea necesario utilizar nuevas tecnologías que solo sean compatibles con los controladores más nuevos (los ejemplos incluyen la autenticación de Azure o la función Siempre cifrado).

¿Necesito ambos?

Solo si usa DAO y ADO. En términos generales, todos los formularios e informes y consultas de Access siempre usan DAO. La única vez que puede usar ADO es dentro del código VBA. Entonces, si no usa ADO, puede salirse con la suya solo con el controlador ODBC y eso debería ser suficiente para su necesidad. Eso significa que cuando normalmente vincula sus tablas, usaría un código similar al siguiente:

Dim db As DAO.Database
Dim tdf As DAO.TableDef
 
Set db = CurrentDb
Set 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

La sintaxis utilizada para tdf.Connect funciona para la consulta de transferencia de paso o incluso para la propiedad Connect del método DAO.Workspace.OpenDatabase.

Es legal abrir conexiones ADO usando ODBC, pero la desventaja es que termina atravesando más capas porque estaría usando el proveedor OLEDB para ODBC y conectarse con el controlador ODBC 17 para SQL Server. Si aún prefiere usar ODBC de todos modos, puede usar el siguiente código para usar ODBC sobre 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

Es mejor evitar la capa extra y usar el OLEDB directamente. Puede usar este código para obtener el mejor rendimiento con su código ADO:

Dim con As ADODB.Connection
 
Set con = New ADODB.Connection
con.ConnectionString = "Provider=MSOLEDBSQL;Server=myServer; Database=myDataBase;"
con.Open

Por lo tanto, la única vez que realmente necesitará y usará el nuevo controlador OLEDB para SQL Server es cuando tenga el código ADO en su aplicación y desee usar la capacidad total de ADO, que debe habilitarse con el controlador OLEDB subyacente.

Referencia adicional

Hoja de ruta para la tecnología de acceso a datos de Microsoft