Si ya hace años que sigues lo que publico sabrás que soy un gran admirador de la tecnología de Microsoft, pero al mismo tiempo un gran crítico de la nefasta comunicación de producto que tiene la empresa, especialmente de cara a los desarrolladores. Históricamente, debido a las malas decisiones de markcomm, han complicado innecesariamente la vida de los que nos dedicamos a esto de la programación.
El caso más nefasto ha sido seguramente todo el lío de .NET, pero existen muchos otros. Y hoy, precisamente, te voy a hablar de uno de ellos: la maraña enrevesada de nombres de tecnologías para acceso a datos con SQL Server. De hecho, me verás poner un "facepalm" o varios en el siguiente texto con algunas burradas que hicieron 😉
Al final de este post estarás en condiciones de conocer las diferentes tecnologías que ofrece Microsoft para acceso a datos en general y a SQL Server en particular, cuáles están obsoletas y deberías desechar y cuáles deberías utilizar según el lenguaje o plataforma que utilices.
Vamos a ello...
Tecnologías de acceso a datos nativas de Microsoft
Vamos a hacer un repaso de las tecnologías de acceso a SQL Server para desarrolladores Microsoft que tiene la propia Microsoft, y que es más larga de lo que seguramente te piensas, sobre todo si consideramos todas sus versiones y cambios de nombre:
1.- ODBC
Esta es la tecnología clásica y que te permite conectarte a SQL Server desde cualquier lenguaje o plataforma, ya que está basada en un estándar de la industria: Open DataBase Connectivity (ODBC). Es lo que debes utilizar si tu tecnología no tiene un conector específico. Por ejemplo con C/C++.
Todos los gestores de bases de datos relacionales que puedas imaginar tienen un controlador para ODBC y, por supuesto, SQL Server también.
¿Sabías que... Microsoft es la empresa que creó (junto a la canadiense Simba Tecnologies) la especificación inicial de ODBC a principios de los años '90 del siglo pasado que luego se estandarizó?
Existen 3 generaciones diferentes del driver ODBC para SQL Server:
- La primera generación, el ODBC Driver for SQL Server, venía incluida con los Windows Data Access Components (que luego se pasaron a llamar Microsoft Data Access Components o MDAC 🤦🏻♂️), es decir, que venían directamente con el sistema operativo. De hecho, siguen viniendo con Windows por compatibilidad, pero no se recomienda su uso aunque funcionen, porque están obsoletos.
- La segunda generación se incluyó con SQL Server desde su versión 2005 hasta la versión 2012, y era parte integral del SQL Server Native Client o SQLNCLI (más adelante te explico qué es). También está obsoleto y, aunque funciona, no se recomienda su uso.
- La tercera generación se llama Microsoft ODBC Driver for SQL Server y, como ves, deja muy claro que los anteriores ya no sirven (nótese la ironía en la afirmación. Insisto: son un verdadero desastre con estas cosas). Es el que se debe utilizar para cualquier versión de SQL Server posterior a la 2012.
2.- OLE DB
OLE (Object Linking and Embedding) es el nombre de la tecnología más antigua de Microsoft para intercomunicación entre aplicaciones y creación de componentes de software, que se lanzó nada menos que en 1990.
OLE DB es una tecnología nativa de Windows que permite el acceso a cualquier base de datos, siempre que esta disponga de un proveedor (sinónimo de driver en la jerga OLE DB) para OLE DB. Existen proveedores OLE DB para la práctica totalidad de bases de datos relacionales del mercado.
Un detalle interesante es que esta tecnología incluye un controlador para acceso a datos a través de ODBC (Microsoft OLE DB Provider for ODBC, que se denomina MSDASQL aunque no tenga nada que ver con el nombre, para "facilitar" más que nos entendamos 🤦🏻♂️). De este modo si tu base de datos favorita no tiene un controlador OLEDB, con toda seguridad que tiene uno ODBC por lo que podrías seguir usando OLEDB para acceder a ella mediante esta capa indirecta.
Al igual que en el caso de ODBC, existen 3 generaciones de esta tecnología a la hora de acceder a datos con SQL Server:
- OLE DB Provider for SQL Server (SQLOLEDB), que al igual que la primera generación de ODBC forma parte de MDAC y se incluye en Windows, pero está obsoleto y no deberíamos utilizarlo.
- El OLE DB Provider interface incluido también con el SQL Server Native Client (SQLNCLI), que estuvo en desarrollo activo desde las versiones de SQL Server de la 2012 a la 2017 (algo más que la segunda generación de ODBC). Se declaró obsoleto en 2011, pero no te pierdas el giro de guion acto seguido...
- La tercera generación se denomina Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) y, no te lo pierdas, es en realidad la generación anterior "des-deprecada" en 2018 (🤦🏻♂️🤦🏻♂️🤦🏻♂️), 7 años después de haberla declarado obsoleta. Lo bueno es que lanzaron con ella una nueva versión y la siguen actualizando y manteniendo hoy en día. Lo puedes descargar desde aquí.
Lo importante aquí respecto a SQL Server es saber que, cuando rehabilitaron la tecnología y sacaron la tercera generación, cambiaron la cadena de conexión. Si tus aplicaciones se conectan a SQL Server usando un cadena de conexión que comience con Provider=SQLOLEDB deberías cambiarla a Provider=MSOLEDBSQL. La primera cadena de conexión utiliza la generación antigua del driver, mientras que la segunda utiliza la actual y podrá sacar partido de las novedades de la base de datos y de las mejoras de rendimiento, estabilidad y seguridad que conlleva.
3.- ADO
La siguiente generación del modelo de componentes de software de Microsoft, llamado a sustituir a OLE se denominó ActiveX, y nació en 1996. Junto a ActiveX surgió una nueva tecnología de acceso a datos llamada ADO (ActiveX Data Objects).
ADO se construye por encima de OLEDB y aunque, debido a ello, da algo menos de rendimiento que usar directamente OLEDB, es mucho más fácil de aprender y utilizar.
Para acceder a datos con ADO utilizarás ADO con un driver OLE DB para la base de datos que te interese. En el caso de SQL Server utilizarás ADO con el driver de tercera generación de OLEDB que hemos visto en el punto anterior (¡fíjate en la cadena de conexión)!.
ADO tiene extensiones para acceder a bases de datos multidimensionales (ADOMD) e incluso para gestión de las bases de datos y de su seguridad (ADOX que es el acrónimo de ADO Extensions for DDL and Security: todo "palabros" para no liar al personal, ya sabes).
Es el método de acceso a datos que usarás con tecnologías antiguas como Visual Basic 6, ASP clásico, macros de Excel con VBA... que, a pesar de la cantidad de años que tienen, siguen siendo muy utilizadas, sobre todo lo último (VBA).
Tienen también su propia historia confusa de versiones (no tanto de terminología, en ese enlace falta la 6.1) ya que al principio se instalaban de manera independiente pero luego empezaron a incluirlas con el sistema operativo. Por ejemplo, con Windows XP y Windows Server 2003 venía ADO 2.8, que seguía la numeración tradicional que comenzó con ADO 2.0, pero al llegar Windows Vista decidieron que le iban a llamar ADO 6.0 por algún motivo, y luego con Windows 7 llegó ADO 6.1. Ambos eran equivalentes en todo a ADO 2.8, pero because reasons, los numeraron así 🤦🏻♂️ Por eso ahora si quieres añadir a un proyecto .NET soporte para ADO, te encuentras con esto:
y te preguntas qué versión añadir y por qué. Yo te recomendaría que la 2.8: es la más común y exactamente igual a las posteriores. En fin...
4.- ADO.NET
Cuando apareció la primera versión final de .NET framework en 2002, siguiendo con las malas decisiones de naming, Microsoft decidió llamar a la tecnología de acceso a datos de la nueva plataforma ADO.NET. Supongo que el objetivo era quitarle miedo a los que debían migrar desde tecnologías anteriores para que les pareciese que era lo mismo. Pero no tenía nada que ver ni con ActiveX ni con el modelo de objetos que se utilizaba con ADO "clásico", por lo que fue una elección horrible en mi opinión (🤦🏻♂️).
ADO.NET es un conjunto de clases que permiten hacer acceso a datos nativamente con cualquier versión de .NET. Además, permiten realizar el acceso a cualquier tipo de almacén de datos: no solo bases de datos relacionales sino también bases de datos no-SQL, multidimensionales, etc... Mientras haya un driver apropiado, te servirá, lo cual es sensacional.
El modelo de objetos de ADO.NET es muy simple y, en ese sentido, sí que es similar a ADO ya que es fácil de aprender y de utilizar, y además es muy rápido, pero no tienen nada que ver.
Hoy en día, dado que no permite utilizar directamente objetos (o sea, no es un ORM), ha perdido mucho protagonismo respecto a opciones como Entity Framework, NHibernate o Dapper (este último está mucho más cerca a él en su sencillez y forma de uso y por eso le gusta tanto a mucha gente, entre ellos a mí). Pero no hay que olvidar que todos ellos utilizan ADO.NET por debajo. Por ello ADO.NET se sigue soportando, actualizando y manteniendo en las versiones más modernas de .NET. Es decir, aunque alguien te puede decir lo contrario, no está obsoleto y sigue siendo el método de acceso a datos nativo de .NET, aunque no le puedes sacar partido al manejo directo de objetos o a Linq.
Para poder conectarte con ADO.NET (o tecnologías "por encima" de este) a un determinado gestor de datos necesitas lo que se llama un proveedor de datos para ese gestor de datos. En el caso de SQL Server (sorpresa, sorpresa) existen 2 proveedores de ADO.NET que están soportados tanto en .NET "clásico" como en .NET Core o .NET:
- System.Data.SqlClient: es el clásico de toda la vida que salió junto a .NET framework en 2002 y que se fue actualizando de manera constante a lo largo de los años. Desde 2019, tras el último golpe absurdo de timón de Microsoft con .NET (cuando decidieron cargarse la denominación .NET Core y dejarlo solo como .NET), lo han dejado de mantener (solo seguridad) como parte integral del framework y ahora es un paquete NuGet aparte (esto sí que me parece bien) pero con un nombre diferente, que es...
- Microsoft.Data.SqlClient: fíjate en que lo que ha cambiado es el espacio de nombres raíz que utiliza que pasa de
System a Microsoft, lo cual era necesario al separarlo de la plataforma para evitar conflictos con código ya existente, pero no deja de ser una "cagada". Esta versión se basa en la otra, pero la sigue evolucionando de manera independiente a la plataforma. Su nombre oficial es Microsoft SqlClient Data Provider for SQL Server y es la que deberíamos utilizar.
La versión clásica "System" sigue formando parte de la plataforma, sigue estando soportada por Microsoft y la puedes utilizar si quieres, pero no es recomendable porque no va a evolucionar ni a añadir nuevas funcionalidades a medida que avance SQL Server. Por lo tanto, si todavía la estás utilizando deberías migrar tus aplicaciones a la versión Microsoft, usando el paquete Nuget correspondiente.
Como nota de interés y para cerrar el círculo, en Windows ADO.NET es capaz de utilizar los proveedores OLE DB para acceder a bases de datos que no tengan un proveedor nativo para ADO.NET, dándole más amplitud a la hora de ser utilizado. Fíjate en que cada tecnología es capaz de usar a las anteriores, más antiguas, mejorando la compatibilidad y aumentando las opciones. Ya te dije que en Microsoft son muy buenos en tecnología aunque sean muy malos en markcomm 😉
Acceso a SQL Server desde otros lenguajes y plataformas
Además de las tecnologías y drivers nativos que tiene Microsoft para acceso a SQL Server desde sus sistemas operativos y plataformas de desarrollo, también dispone de implementaciones para otras plataformas de programación. La siguiente lista te indica los que ha creado Microsoft directamente (que yo conozco al menos), pero existen drivers creados por otras empresas para acceder a SQL Server desde otros entornos y lenguajes:
Otras tecnologías de acceso a datos nativas de Microsoft
Con lo anterior he repasado las tecnologías habituales para acceder a SQL Server, pero todavía hay más. Conviene conocerlas para no confundirnos y porque, como digo, la maraña de nombres que ha ido creando Microsoft a lo largo de los años merece ser un caso de estudio en alguna escuela de negocios de prestigio sobre cómo NO hacer las cosas. Demos un repaso rápido:
SQL Server Native Client
Conocido también como SNAC (o SQLNCLI), se incluyó con SQL Server entre sus versiones 2005 y 2012. Incorpora todo lo necesario para poder hacer acceso a datos con SQL Server tanto con ODBC (segunda generación) como con OLEDB (segunda generación también).
A partir de SQL Server 2012 se declaró como obsoleto aunque, si no tienes que sacar partido a las nuevas características del gestor, podrías seguir utilizándolo, pero no es recomendable.
Si tu aplicación utiliza Provider=SQLNCLI en la cadena de conexión, cámbialo al proveedor OLE DB más reciente: Provider=MSOLEDBSQL.
Microsoft/Windows Data Access Components
Inicialmente llamado MDAC, luego WDAC (al cambiar la palabra "Windows" por "Microsoft" en su nombre), se trata de un conjunto de componentes para acceso a datos que vienen incluidos con Windows y Windows Server desde hace muchos años, y que incluyen las tecnologías ODBC, OLE DB y ADO (con sus extensiones) y los drivers para SQL Server (y aplicaciones Office: el clásico motor Jet, y de Oracle entre otros) en todas ellas.
Son parte integral del sistema operativo por lo que siempre van a estar disponibles y se siguen actualizando en lo que se refiere a la seguridad.
Siguen incluyendo versiones ya declaradas obsoletas de los drivers que hemos visto para ODBC y OLE DB, incluso en las versiones más modernas de Windows, pero Microsoft ha manifestado que quizá en una versión futura de Windows los elimine. Pero, hoy por hoy, los puedes seguir usando con la confianza de que están disponibles aunque no puedan sacar partido a cuestiones nuevas de SQL Server.
Otras completamente obsoletas
Por completitud y para que te suenen, te dejo una lista rápida de otras tecnologías nativas de Microsoft para acceso a datos que ya no existen pero de las que podrás leer online y que te saldrán a veces búsquedas. ¡No las uses aunque puedas!
- DAO: los míticos Data Access Objects fueron muy utilizados porque se incluían con el motor Jet para Access y Excel, y se utilizaban desde código VBA para crear macros y acceder a bases de datos de escritorio creadas con Microsoft Access. Siguen existiendo en estos productos pero solo en las versiones de 32 bits, ya que nunca se portaron a 64 bits.
- RDO: o Remote Data Objects, que se diseñaron para hacer acceso a datos a través de ODBC a fuentes de datos remotas, simplificando el código. Fueron muy populares en la época de Visual Basic 6 (aunque salieron ya con VB 4.0), y murieron con esta plataforma. No eran específicos de SQL Server.
- DB-Library: era una biblioteca de acceso a SQL Server específica para el lenguaje C. Su última versión fue con SQL Server 2000 😵. - E-SQL: o Embedded SQL era un modelo de programación específico para SQL Server que permitía incluir directamente instrucciones Transact-SQL en código fuente C. Una virguería, en cierto modo precursor de Linq, y que facilitaba mucho la vida a los programadores de C/C++. Murió también con SQL Server 2000.
En resumen
Para resumir todo lo anterior y tener un mapa sobre cuál es el sistema para acceder a SQL Server que debieses utilizar, te dejo la siguiente lista:
- Si vas a trabajar con .NET utiliza
Microsoft.Data.SQLClient. Si empleas un ORM como Entity Framework, el driver que utilizarás por debajo es este.
- Si trabajas con .NET framework "clásico", entonces puedes ir con
System.Data.SQLClient. Lo tendrás más complicado con características muy recientes de SQL Server pero, si lo necesitas, puedes instalar desde NuGet el paquete para Microsoft.Data.SqlClient (aunque trae bastantes dependencias en este caso). también puedes recurrir al driver más reciente para OLE DB a través del proveedor para OLE DB de .NET.
- Si programas con VBA en Office, ASP Clásico, o un entorno nativo de Windows antiguo, deberás utilizar la versión más reciente de ADO con el proveedor para OLE DB de SQL Server más reciente. Es decir, asegurándote de que pones
Provider=MSOLEDBSQL en la cadena de conexión, y no una más antigua.
- Si programas con C/C++ (en Windows) deberás utilizar ODBC.
¡Espero que te resulte útil!
Fecha de publicación: