Teoría BBDD

La collation (intercalación) es uno de esos conceptos cruciales de SQL Server y Azure SQL sin embargo, a menudo se pasa por alto o se confunde con otros términos como idioma o codificación. Dado que la collation impacta directamente en la forma en que se procesan las consultas de texto, su correcta configuración es vital para evitar problemas de rendimiento y coherencia en nuestras aplicaciones. En resumen, la collation define cómo se ordenan y comparan los datos de texto en una base de datos, incluyendo reglas sobre la sensibilidad a mayúsculas, acentos y otros caracteres especiales. Es de esas configuraciones de las que uno solo se acuerda cuando tiene un error y ya es tarde para solucionarlo.

¿Qué es la Collation?

La collation en SQL Server es una configuración que define las reglas para comparar y ordenar cadenas de texto. Estas reglas determinan, por ejemplo, si las comparaciones deben ser sensibles a mayúsculas o minúsculas (case-sensitive o case-insensitive), si deben distinguir entre caracteres con y sin acento (accent-sensitive o accent-insensitive), y cómo se ordenan los caracteres según un conjunto de reglas culturales o técnicas específicas.

Una confusión común es suponer que al establecer una collation se está configurando el idioma de la base de datos o la codificación de los datos. Esto no es correcto. Es importante entender que la collation no es lo mismo que el idioma o la codificación de los caracteres.

Diferencias entre intercalación, idioma y codificación

Mientras que la collation puede estar basada en un conjunto de reglas lingüísticas propias de un idioma (por ejemplo, cómo se ordenan las letras en español), no impone que los datos en la base de datos estén escritos en ese idioma.

El idioma, por definición, se refiere al conjunto de reglas gramaticales y de escritura utilizadas en un texto. La codificación, por su parte, la podemos definir como la manera de representar los caracteres en bytes (por ejemplo, UTF-8 o ASCII). Aunque la collation puede estar influenciada por el idioma, ya que define las reglas de ordenación basadas en ese idioma, no determina el idioma del texto en sí.

Por otro lado, la codificación se encarga de la representación física de los caracteres, es decir, cómo los caracteres son almacenados y transmitidos. SQL Server usa la collation para interpretar estas representaciones y aplicar las reglas correctas durante las comparaciones y ordenaciones, independientemente de la codificación subyacente.

Por ejemplo, si seleccionamos una collation basada en inglés, como SQL_Latin1_General_CP1_CI_AS, esta permitirá que las comparaciones de texto sean insensibles a mayúsculas y acentos, de acuerdo con las reglas del idioma inglés. Sin embargo, esto no impide que los datos almacenados estén en otro idioma, como español o alemán; simplemente determina cómo se manejarán y ordenarán esos datos.

En cuanto a la codificación, ésta se refiere a cómo los datos se almacenan y se interpretan a nivel de bytes. SQL Server maneja esto automáticamente, y la collation se encarga de aplicar las reglas adecuadas durante las operaciones con texto, como ORDER BY o WHERE.

Niveles de Intercalación

SQL Server está preparado para manejar distintas collation a nivel de instancia , base de datos e incluso columna. Cada una de estas intercalaciones tiene un alcance distinto y, por tanto, si deseamos modificarlas el proceso será diferente. Lo que sí os puedo asegurar es que en todos los casos cambiar una collation es peor que un dolor de muelas. Además, una discrepancia de collation puede ser incompatible con operaciones de comparación de datos o de lectura en un objeto y escritura en otro, existen maneras de salvarlo pero, nuevamente, será un suplicio para el desarrollador.

Collation a nivel de instancia en SQL Server

La collation a nivel de instancia se configura durante la instalación de SQL Server y define el comportamiento predeterminado para todas las bases de datos y objetos creados dentro de esa instancia. Esta collation será la de las bases de datos de datos de sistema y es clave en el futuro comportamiento de SQL Server. Además, si no especificamos una collation al crear después una base de datos de usuario o un objeto, heredará la de la instancia.

Esta collation de instancia influye en la forma en que se gestionan las comparaciones y ordenaciones en todas las bases de datos del sistema, afectando aspectos como la sensibilidad a mayúsculas y acentos. Es esencial elegir la collation correcta durante la instalación, ya que cambiarla posteriormente puede ser complicado, requiriendo a veces la reinstalación del servidor o la migración de las bases de datos.

Collation a nivel de base de datos

Cada base de datos en SQL Server puede tener su propia collation, independientemente de la collation de la instancia. Esto es útil cuando necesitamos manejar datos en diferentes idiomas o con diferentes requisitos de comparación. Por ejemplo, una base de datos que maneje datos en japonés puede necesitar una collation distinta de otra que gestione datos en francés no por el idioma o por el juego de caracteres sino porque los criterios de ordenación de los caracteres cambia.

Al crear una base de datos, podemos especificar la collation utilizando la cláusula COLLATE. Si necesitamos cambiar la collation de una base de datos existente, esto se puede hacer con el comando ALTER DATABASE, aunque el cambio no afectará automáticamente a las tablas y columnas ya existentes. Por lo tanto, si cambiamos la collation de una base de datos, debemos asegurarnos de revisar y actualizar también las collations de las columnas si es necesario.

Collation a nivel de columna

El nivel más granular de collation se encuentra en las columnas de las tablas. Esto nos permite tener columnas con diferentes collations dentro de la misma tabla, lo cual es especialmente útil en escenarios donde necesitamos manejar datos de diferentes orígenes o con distintos requisitos culturales.

Para definir la collation de una columna al momento de crear una tabla, utilizamos la cláusula COLLATE después del tipo de dato de la columna. Si necesitamos cambiar la collation de una columna existente, podemos hacerlo con el comando ALTER TABLE ALTER COLUMN, aunque este proceso puede ser costoso en términos de rendimiento, especialmente si la tabla contiene grandes volúmenes de datos.

Cómo trabajar con datos con distinta Collation

Trabajar con datos que tienen diferentes collations requiere precaución, especialmente al realizar comparaciones o uniones entre columnas. SQL Server permite especificar la collation en las consultas utilizando la cláusula COLLATE en las expresiones de texto, lo que nos permite unificar la collation de los datos en una operación específica. Esta es la única forma de poder actuar cuando tenemos distintas collations entre objetos, por ejemplo, entre bases de datos e instancia que, como hemos visto antes afecta a las bases de datos de sistema y por tanto a las tablas temporales en TempDB.

Otro ejemplo, si tenemos dos columnas con diferentes collations y necesitamos compararlas, podemos utilizar COLLATE para especificar la collation a usar durante la comparación, evitando así errores cómo «Cannot resolve the collation conflict«. De esta manera, podemos trabajar con datos multilingües o de diferentes fuentes de manera más segura y eficiente.

Cambiar la Collation: Impacto y consideraciones

Cambiar la collation en SQL Server, ya sea a nivel de instancia, base de datos o columna, no es una tarea trivial y debemos realizarla con precaución. Los cambios a nivel de instancia son los más delicados, ya que afectan a todas las bases de datos y objetos de esa instancia. Esto implica una reinstalación de facto de la instancia y, aunque no perderemos los datos, sí que pueden verse afectados los objetos de instancia como logins, credenciales, etc…

A nivel de base de datos, es fundamental considerar que las tablas y columnas existentes no cambiarán automáticamente, lo que podría llevar a una mezcla de collations dentro de la misma base de datos. Este tipo de situaciones complican la gestión y pueden dar lugar a problemas de rendimiento o coherencia de datos. Por ello, es crucial planificar estos cambios con antelación y realizar pruebas exhaustivas en un entorno controlado antes de aplicarlos en producción.

Conclusión

La correcta gestión de la collation en SQL Server y Azure SQL es esencial para garantizar la integridad y el rendimiento de nuestras bases de datos. Entender las diferencias entre collation, idioma y codificación nos permite tomar decisiones más informadas y evitar errores comunes que pueden surgir al trabajar con datos multilingües o de diferentes fuentes. Al aplicar las mejores prácticas en la configuración y el manejo de collations, podemos optimizar nuestras bases de datos para un rendimiento y consistencia óptimos, asegurando que nuestras aplicaciones manejen datos de texto de manera eficaz y sin sorpresas inesperadas.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

No te vayas aun. Hemos creado una página donde estamos recopilando todos estos artículos que dan respuesta a estas preguntas frecuentes de SQL Server. Pásate por aquí a echar un vistazo.

Uno de los conceptos fundamentales y a los que más atención debemos prestar cuando trabajamos con bases de datos es el de las transacciones. Las transacciones nos permiten agrupar una serie de operaciones en una única unidad de trabajo. Dentro de este contexto, dos comandos clave son COMMIT y ROLLBACK, que nos permiten confirmar o deshacer transacciones respectivamente. Pero también existen otros aspectos fundamentales que debemos conocer como las transacciones implícitas y explícitas y los conceptos BEGIN TRAN, BEGIN TRY y BEGIN CATCH. Si todo esto te suena a chino no te preocupes, acompáñame en este artículo en el que profundicemos en estos conceptos y en cómo la gestión de transacciones puede influir en nuestra estrategia de manejo de datos.

¿Qué son las transacciones?

Una transacción es un conjunto de operaciones SQL que se ejecutan como una unidad indivisible. El principio básico es que todas las operaciones dentro de una transacción deben completarse con éxito; de lo contrario, ninguna de ellas se aplicará. Este comportamiento garantiza la integridad y consistencia de los datos. 

Si echamos la vista atrás, cuando empezamos a estudiar bases de datos relacionales siempre nos dicen que se basan en el concepto ACID, que es un acrónimo que hace referencia a un conjunto de propiedades fundamentales que aseguran que las transacciones se manejen de manera confiable.

Propiedades ACID

Las transacciones en bases de datos relacionales como SQL Server deben cumplir con las propiedades ACID. Pero, ¿qué es ACID? ACID son las iniciales de Atomicidad, Consistencia, Aislamiento (Isolation en inglés) y Durabilidad. Veamos qué significa:

Atomicidad (Atomicity): Una transacción debe ser atómica, es decir, todas las operaciones dentro de una transacción se consideran como una sola unidad. Cuando una transacción tiene varios pasos, o se ejecutan todos o ninguno. Si alguna operación falla, toda la transacción debe fallar y deshacerse.

Consistencia (Consistency): Una transacción debe llevar la base de datos de un estado consistente a otro estado consistente. Esto significa que las reglas y restricciones de la base de datos deben ser respetadas antes y después de la transacción.

Aislamiento (Isolation): Las transacciones concurrentes deben aislarse unas de otras y cada transacción debe ser independiente. Esto asegura que las transacciones no afecten el estado intermedio de otras transacciones en curso.

Durabilidad (Durability): Una vez que una transacción ha sido confirmada (COMMIT), los cambios realizados deben persistir en la base de datos, incluso en caso de fallos del sistema.

Commit: Confirmando transacciones

El comando COMMIT se utiliza para confirmar una transacción, haciendo permanentes todos los cambios realizados desde el inicio de la misma. Una vez que se emite un COMMIT, no hay marcha atrás: los cambios quedan guardados en la base de datos de forma definitiva.

BEGIN TRANSACTION
-- Operaciones SQL como INSERT, UPDATE o DELETE
COMMIT;

En este bloque de código, cualquier operación SQL entre BEGIN TRANSACTION y COMMIT será confirmada y guardada permanentemente al ejecutar el COMMIT.

Rollback: Deshaciendo transacciones

El comando ROLLBACK es el contrario a COMMIT. Nos permite deshacer todas las operaciones realizadas en la transacción actual, volviendo la base de datos a su estado anterior al inicio de la transacción. Esto es esencial para manejar errores y mantener la integridad de los datos.

BEGIN TRANSACTION
-- Operaciones SQL como INSERT, UPDATE o DELETE
ROLLBACK;

Aquí, si algo sale mal o si detectamos algún error en las operaciones SQL, el ROLLBACK deshará todos los cambios desde el BEGIN TRANSACTION, asegurando que la base de datos no quede en un estado inconsistente.

Manejo avanzado de transacciones: BEGIN TRAN, TRY, CATCH

Para un manejo más completo de las transacciones, SQL Server ofrece estructuras adicionales como BEGIN TRANSACTION (o su abreviatura BEGIN TRAN), BEGIN TRY y BEGIN CATCH, que nos permiten manejar errores de manera efectiva dentro de las transacciones.

BEGIN TRAN

El comando BEGIN TRANSACTION o BEGIN TRAN se utiliza para iniciar una nueva transacción. Este comando es esencial cuando queremos agrupar varias operaciones SQL en una sola unidad de trabajo. La sintaxis es la que ya hemos estado viendo en los anteriores ejemplos:

BEGIN TRAN
-- Operaciones SQL como INSERT, UPDATE o DELETE
COMMIT;

TRY y CATCH

Las estructuras TRY y CATCH en SQL Server nos permiten capturar y manejar errores dentro de las transacciones. Utilizando BEGIN TRY y BEGIN CATCH, podemos definir bloques de código que se ejecutan en caso de éxito o fallo de la transacción.

BEGIN TRY
    BEGIN TRANSACTION
    -- Operaciones SQL como INSERT, UPDATE o DELETE
    COMMIT
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK
    – Operaciones de manejo de errores como escribir un log
    PRINT ERROR_MESSAGE()
END CATCH;

En este ejemplo, si alguna operación dentro del bloque TRY falla, el control pasa al bloque CATCH, donde podemos realizar un ROLLBACK y manejar el error de manera apropiada.

Transacciones implícitas en SSMS

En SQL Server Management Studio, las transacciones por defecto son automáticas, es decir, no es necesario declarar el BEGIN TRANSACTION al inicio ni el COMMIT al terminar, se hará automáticamente. Sin embargo, pueden ser configuradas para ser implícitas y que debamos ser nosotros quienes elijamos si hacer COMMIT o ROLLBACK. Esto significa que cada operación individual se convierte automáticamente en una transacción. Aunque puede parecer ventajoso, esta configuración tiene tanto ventajas como inconvenientes. Si la transacción es abierta manualmente con un BEGIN TRANSACTION entonces hablamos de transacciones explícitas.

En resumen, el comportamiento por defecto son las transacciones automáticas y cada operación es una transacción individual que se confirma (COMMIT) automáticamente. Podemos definir de manera explícita una transacción con BEGIN TRANSACTION y perdurará hasta que hagamos un COMMIT o ROLLBACK manualmente. Si lo que queremos es anular el COMMIT automático en las operaciones individuales podemos configurar las transacciones implícitas.

Ventajas de las transacciones implícitas

Una de las principales ventajas de las transacciones implícitas es que no necesitamos preocuparnos por envolver nuestras operaciones en bloques de transacción explícitos. Esto puede simplificar el código y reducir errores por omisión de transacciones. Además, en escenarios de producción puede reducir el riesgo de errores por ejecución de código no deseado.

Inconvenientes de las transacciones implícitas

Sin embargo, las transacciones implícitas también tienen importantes desventajas. La principal es el riesgo de olvidar confirmar o deshacer una transacción, lo que puede llevar a bloqueos o a un uso excesivo de recursos. Otro de los problemas comunes es que mientras una transacción esté abierta el log no se va a vaciar, pudiendo crecer descontroladamente. Por último, al no ser automáticas ni explícitas, es más difícil llevar un control riguroso de cuándo se inician y terminan las transacciones, lo cual puede complicar la depuración y el mantenimiento del código. Además, la automatización de transacciones puede generar una sobrecarga innecesaria en operaciones simples que no requieren aislamiento transaccional.

Configuración de transacciones implícitas en SSMS

Para habilitar las transacciones implícitas en SSMS, debemos modificar una configuración específica. En SSMS, vamos a Tools > Options > Query Execution > SQL Server > ANSI, y activamos la opción «SET IMPLICIT_TRANSACTIONS». Esto cambia el comportamiento predeterminado de las consultas ejecutadas en el editor.

Una vez activada esta opción, cada instrucción SQL iniciará automáticamente una transacción que deberá ser confirmada con COMMIT o deshecha con ROLLBACK. Es crucial recordar en todo momento que hemos activado este comportamiento para evitar los problemas que acabamos de describir hace un momento.

Por otro lado, independientemente de la configuración general de nuestro SSMS o cuando estamos trabajando con otras herramientas es posible editar este comportamiento para una sesión en concreto. Esto lo haremos con el comando SET IMPLICIT_TRANSACTION seguido de un valor ON u OFF en función de lo que deseemos.

Buenas Prácticas en la gestión de transacciones

Para maximizar el beneficio de controlar manualmente las transacciones y minimizar los riesgos, es esencial seguir algunas buenas prácticas. Primero, debemos asegurar que las transacciones sean de un tamaño aceptable. Como norma general una transacción que afecte a varios registros será más eficiente que muchas transacciones individuales pero hasta cierto punto. Llega un momento que el tamaño de la transacción puede acarrear problemas. Existe una recomendación aproximada de no superar los 10.000 registros por transacción pero depende en gran medida de la complejidad de la misma y del volumen de los datos. Lo que sí está claro es que esto nos va a reducir la probabilidad de sufrir bloqueos y a mejorar el rendimiento general de nuestro servidor. También es recomendable incluir manejo de errores dentro de nuestras transacciones para poder realizar un ROLLBACK automático en caso de fallos.

Conclusión

El manejo adecuado de transacciones en SQL Server mediante los comandos COMMIT y ROLLBACK es fundamental para asegurar la integridad y consistencia de nuestros datos. Además, las transacciones implícitas nos pueden ofrecer ventajas en términos de simplicidad y rapidez de desarrollo, pero siempre prestando atención, pues tienen riesgos que debemos gestionar con cuidado. Entender estos conceptos y aplicar buenas prácticas nos permitirá desarrollar sistemas más robustos y eficientes.

 Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

No te vayas aun. Hemos creado una página donde estamos recopilando todos estos artículos que dan respuesta a estas preguntas frecuentes de SQL Server. Pásate por aquí a echar un vistazo. 

Cuando trabajamos con SQL Server, uno de los elementos más críticos y, a menudo, menos comprendidos es el log de transacciones. Este componente de las bases de datos es esencial para asegurar la integridad y consistencia de nuestros datos. Gracias a este registro de transacciones, el motor de base de datos va a poder llevar a cabo una recuperación completa en caso de fallo. También se usa para la replicación de datos, una vez sincronizada una base de datos lo que se replica en tiempo real son las operaciones que registra el log. 

¿Qué es el Log de Transacciones?

El log de transacciones es una archivo de base de datos que se almacena con una estructura de datos secuencial y que registra todas las modificaciones hechas a la base de datos. Cada cambio, sea cual sea, desde una simple inserción hasta una transacción compleja, se documenta en el log antes de ser aplicado físicamente a la base de datos. Gracias a esta característica podemos estar seguros de que en caso de un fallo del sistema, vamos a poder recuperar la base de datos a su estado anterior sin pérdida de datos.

Entender cómo funcionan los logs de transacciones es, por tanto, clave para cualquier DBA ya que sin ellos no funcionan nuestras bases de datos. En este artículo hablamos un poco más sobre el tema. 

Por otro lado, los logs se organizan en una serie de segmentos denominados VLFs (Virtual Log Files). SQL Server gestiona estos VLFs automáticamente, pero es fundamental entender su funcionamiento para evitar problemas de rendimiento. Cuando el log de transacciones crece, se añaden más VLFs, y si no se gestionan adecuadamente, pueden llevar a una fragmentación del log, lo que afecta negativamente al rendimiento.También hablamos sobre ellos en el blog, puedes profundizar más sobre este tema aquí. 

Importancia del Modo de Recuperación

El modo de recuperación de la base de datos determina cómo se gestionan los logs de transacciones y, en última instancia, cómo se pueden recuperar los datos. SQL Server ofrece tres modos de recuperación: Simple, Completo y Bulk-Logged.

En el modo de recuperación Simple, el log de transacciones se trunca automáticamente después de cada checkpoint, limitando las opciones de recuperación a los backups completos. El modo de recuperación Full (completo), por otro lado, permite una recuperación total hasta el punto de fallo, siempre y cuando se mantenga un régimen adecuado de backups de logs de transacciones. Finalmente, el modo de recuperación Bulk-Logged ofrece un compromiso entre los dos anteriores. Este modo minimiza las escrituras en log durante operaciones masivas, como cargas de datos, a cambio de una menor granularidad en la recuperación.

Optimización y Mantenimiento del Log de Transacciones

Para asegurar un rendimiento óptimo del log de transacciones, es crucial seguir ciertas prácticas de mantenimiento y optimización. Primero, es esencial monitorizar el tamaño del log y evitar que crezca indefinidamente. Esto se logra configurando adecuadamente el tamaño inicial del log y sus incrementos automáticos, así como realizando backups regulares del log de transacciones en los modos de recuperación distintos a simple.

Otro aspecto vital es la gestión de los VLFs. Un número excesivo de VLFs puede degradar el rendimiento, por lo que es recomendable mantenerlos en un rango razonable. Esto se puede controlar ajustando los incrementos automáticos del tamaño del log, evitando incrementos pequeños que resulten en una gran cantidad de VLFs. 

Accediendo al Log de Transacciones

Acceder a los logs de transacciones nos puede parecer una tarea intimidante al principio, pero SQL Server nos proporciona varias herramientas para facilitar este proceso. La forma más común de acceso es a través de la función fn_dblog, que permite visualizar el contenido del log directamente desde SQL Server Management Studio (SSMS). Consultando esta función, obtendremos una lista detallada de todas las transacciones registradas. Esta operación, nos permite a los DBAs una visión sin filtros de cada operación, pero es importante manejar la cantidad de información con precaución, ya que puede ser abrumadora.

 SELECT * FROM fn_dblog(NULL, NULL)

 Interpretando los Datos del Log

Una vez que hemos accedido al log, el siguiente paso es interpretar los datos. Cada registro en el log contiene múltiples columnas que describen la transacción en detalle. Algunas de las columnas más relevantes incluyen:

• Transaction ID: Identificador único de la transacción.
• Operation: Tipo de operación realizada (inserción, eliminación, actualización, etc.).
• Transaction Name: Nombre de la transacción, si se ha especificado.
• Begin Time: Hora de inicio de la transacción.
• End Time: Hora de finalización de la transacción.

Comprender estas columnas nos permite seguir el rastro de cada transacción y analizar su impacto en la base de datos. Por ejemplo, podemos identificar transacciones largas que podrían estar afectando el rendimiento o detectar operaciones no autorizadas.

Uso de DBCC LOG para el Análisis Avanzado

Para análisis más avanzados, la instrucción DBCC LOG ofrece una visión aún más profunda del log de transacciones. Ejecutando DBCC LOG (<nombre de la base de datos>, <opción de detalle>), podemos especificar el nivel de detalle que queremos obtener. Las opciones de detalle van desde 0 (menos detalle) hasta 4 (máximo detalle), permitiendo ajustar la cantidad de información según nuestras necesidades. Aunque es un procedimiento no documentado, esta herramienta es particularmente útil para investigar problemas específicos o realizar auditorías exhaustivas.

Recuperación de Datos y Auditoría de Seguridad

Uno de los usos más críticos de los logs de transacciones es la recuperación de datos. En situaciones donde se han producido errores o pérdidas de datos, los logs permiten revertir transacciones y restaurar la base de datos a un estado previo consistente. Para llevar a cabo esta tarea, podemos utilizar la instrucción RESTORE LOG junto con el archivo de log de transacciones correspondiente. Es vital tener un plan de backup y recuperación bien definido que incluya la utilización de estos logs.

En cuanto a la auditoría de seguridad, los logs de transacciones son una herramienta invaluable. Al monitorizar y analizar las transacciones registradas, podemos detectar actividades sospechosas o no autorizadas, lo que nos permite tomar medidas preventivas y correctivas a tiempo. Configurar alertas y auditorías basadas en el contenido de los logs nos proporciona una capa adicional de seguridad.

Conclusión

El log de transacciones de SQL Server es un componente fundamental que garantiza la integridad y recuperación de nuestros datos. Comprender su funcionamiento, mantenerlo optimizado y monitorizarlo continuamente nos permite asegurar un rendimiento óptimo y evitar sorpresas desagradables en nuestros entornos de producción más críticos. A través de una gestión cuidadosa y un enfoque proactivo, podemos maximizar la eficiencia de nuestras bases de datos y asegurar su disponibilidad y consistencia en todo momento.

 Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

No te vayas aun. Hemos creado una página donde estamos recopilando todos estos artículos que dan respuesta a estas preguntas frecuentes de SQL Server. Pásate por aquí a echar un vistazo.