sql >> Base de Datos >  >> RDS >> Access

Desenredar los nuevos controladores ODBC y OLEDB de Microsoft SQL Server

Desenredar los nuevos controladores ODBC y OLEDB de Microsoft SQL Server

Es posible que algunos de ustedes ya sepan que Microsoft dio marcha atrás en su desaprobación planificada de OLEDB y proporcionó un nuevo controlador OLEDB. Sin embargo, puede ser un dolor de cabeza averiguar lo que debería estar usando. Cuando usábamos SQL Server Native Client, era bastante fácil:Native Client tenía OLEDB y ODBC enviados en un solo archivo DLL, lo que facilitaba la instalación. Todo lo que tenía que hacer era asegurarse de que estaba 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 ese motivo, Microsoft no ha optado por combinar ODBC y OLEDB en una sola DLL. Si su aplicación contiene código VBA que utiliza tanto DAO como ADO, deberá instalar dos diferentes proveedores para obtener la última función y soporte para ODBC y OLEDB respectivamente.

La convención de nomenclatura puede ser un poco confusa porque muchas personas se referirán vagamente a varios controladores simplemente como "controlador ODBC" o "proveedor OLEDB". Así que aclaremos los nombres. Comenzaremos con la identificación de las versiones obsoletas y luego veremos las versiones actuales.

Versiones obsoletas

De forma predeterminada, todas las versiones de Windows vienen con dos bibliotecas de cliente de acceso 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 están DEPRECATED . Esos tienen como objetivo SQL Server 2000 y carecen de nuevas características introducidas desde entonces. Windows no envíe cualquier controlador nuevo o actualícelo 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 utilícelos en su desarrollo actual.

Versiones actuales

Con eso fuera del camino, veamos el controlador ODBC correcto y el proveedor OLEDB que podemos querer usar.

Controlador ODBC 17 para SQL Server

En el momento de escribir este artículo, el controlador ODBC 17 para SQL Server es el controlador más reciente y se puede descargar en el enlace proporcionado. La cadena de conexión se ve así:

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

Controlador OLE DB 18 para SQL Server

En el momento de escribir este artículo, el controlador OLEDB 18 es el controlador más reciente. Aunque la versión es una superior, el conjunto de funciones es equivalente al controlador ODBC 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 se deben instalar las versiones de 64 o 32 bits del controlador. La respuesta es la misma independientemente de las versiones que estemos 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 ejecutar Access de 32 bits.

¿Puedo usar SQL Server Native Client?

Oficialmente, SQL Server Native Client es compatible con SQL Server 2012. Sin embargo, aún puede usarlo para conectarse a versiones más nuevas de SQL Server. Hay varias funciones 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 de Azure. Si bien es posible que pueda continuar usándolo para sus aplicaciones existentes, le recomendamos que planifique nuevos desarrollos utilizando los controladores ODBC y OLEDB por separado y migre sus aplicaciones existentes cuando sea posible. Debe migrar cuando sea necesario utilizar nuevas tecnologías que solo sean compatibles con esos 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, 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

Establecer db =CurrentDb
Establecer tdf =db.CreateTableDef

tdf.Name =“MyRemoteTable”
tdf.SourceTableName =“dbo.MyRemoteTable”
tdf.Connect =“ODBC;DRIVER=Controlador ODBC 17 para SQL Server;SERVER=myServer;DATABASE=myDatabase;”

db.TableDefs.Append

La sintaxis utilizada para tdf.Connect funciona para pass-through querydef 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 pasando por más capas porque estaría usando el proveedor OLEDB para ODBC para 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

Establezca con =New ADODB.Connection
con.ConnectionString =“DRIVER=Controlador ODBC 17 para SQL Server;SERVER=myServer;DATABASE=myDatabase;”
con.Open

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

Dim con As ADODB.Connection

Establezca 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 código ADO en su aplicación y quiera usar la capacidad completa de ADO, que debe estar habilitada por el controlador OLEDB subyacente.

Referencia adicional

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