Cuando se trabaja con SQL Server, es común encontrarse con situaciones en las que se necesitan generar declaraciones SQL dinámicas. Estas declaraciones pueden volverse bastante largas, especialmente al tratar con dimensiones que tienen numerosas columnas. Sin embargo, es importante tener en cuenta los posibles problemas de truncamiento que pueden surgir.

Recientemente, mientras depuraba mi código SQL dinámico, me di cuenta de que algunas de las declaraciones fallaban con varios errores. Al investigar, descubrí que estas declaraciones se estaban truncando después de 4000 caracteres. Esto planteó la pregunta: ¿qué estaba causando este truncamiento?

En mi código, estaba utilizando la función CONCAT_WS para construir dinámicamente las declaraciones SQL. Esta función permite concatenar múltiples cadenas con un separador especificado. Para asegurar la legibilidad, usé una variable para almacenar un retorno de carro y un salto de línea como separador, lo que resulta en declaraciones de varias líneas con un formato agradable.

Aquí tienes un ejemplo de cómo estaba utilizando la función CONCAT_WS:

DECLARE @crlf CHAR(2) = (CHAR(13) + CHAR(10));
SELECT
    SQLStatement = CONCAT_WS(@crlf
                           ,'SELECT *'
                           ,'FROM dbo.' + m.TableName)
FROM dbo.MyMetadata m;

Sin embargo, el problema no estaba en la función CONCAT_WS en sí. Al revisar la documentación, no encontré ninguna mención de un límite de 4000 caracteres para CONCAT_WS. Esto dificultó un poco la depuración, ya que la ventana de resultados en SQL Server Management Studio (SSMS) también tiene un límite en el número de caracteres que muestra. Además, el comando PRINT también está limitado a 4000 caracteres para nvarchar y 8000 caracteres para varchar.

Para investigar más a fondo, creé un paquete SSIS que ejecutaba el SQL dinámico y generaba el resultado en un archivo CSV. Esto me permitió verificar que los datos se estaban truncando y que no era solo un problema con las ventanas de salida de SSMS o Azure Data Factory.

Después de buscar un poco, descubrí que el truncamiento estaba relacionado con la precedencia del tipo de datos en la función CONCAT_WS (así como en otras funciones de concatenación en SQL Server). Las reglas para la precedencia del tipo de datos se explican mejor en la documentación de la función CONCAT.

En mi caso, como ninguno de los argumentos de entrada de CONCAT_WS superaba los 4000 caracteres, el resultado se convertía automáticamente a NVARCHAR(4000). Para resolver este problema de truncamiento, una solución simple fue realizar una conversión explícita en uno de los parámetros de entrada para forzar que la función devuelva NVARCHAR(MAX), que puede contener cantidades mayores de datos.

Aquí tienes el código modificado con la conversión explícita:

DECLARE @crlf CHAR(2) = (CHAR(13) + CHAR(10));
SELECT
    SQLStatement = CONCAT_WS(@crlf
                           ,CONVERT(NVARCHAR(MAX),'SELECT *')
                           ,'FROM dbo.' + m.TableName)
FROM dbo.MyMetadata m;

Al convertir explícitamente uno de los parámetros de entrada a NVARCHAR(MAX), nos aseguramos de que la función CONCAT_WS devuelva el tipo de datos deseado y elimine el problema de truncamiento.

Comprender los posibles problemas de truncamiento al usar funciones de concatenación en SQL Server es crucial para construir declaraciones SQL dinámicas sólidas y confiables. Siguiendo las conversiones de tipo de datos adecuadas, puedes evitar errores inesperados y garantizar la integridad de tus datos.

La publicación Comprendiendo la concatenación y truncamiento en SQL Server apareció primero en Bajo el manto de la inteligencia empresarial.