Metadatos sin ejecución: domina sys.dm_exec_describe_first_result_set

En el desarrollo de soluciones de Business Intelligence, a menudo nos enfrentamos a la necesidad de conocer la estructura de salida de una consulta antes de que esta devuelva una sola fila. Ya sea porque estamos construyendo un motor de carga dinámico, generando archivos de exportación o mapeando esquemas en Microsoft Fabric, depender de la ejecución real para obtener metadatos es una estrategia ineficiente y, en ocasiones, arriesgada si manejamos volúmenes masivos de datos.

Históricamente, los desarrolladores de SQL Server recurrían a SET FMTONLY ON para obtener la cabecera de un conjunto de resultados. Sin embargo, este método está marcado como obsoleto (deprecated) y presenta comportamientos inconsistentes con consultas complejas. Desde SQL Server 2012, disponemos de la función de administración dinámica sys.dm_exec_describe_first_result_set, una herramienta mucho más robusta que permite al motor de base de datos analizar la semántica de la consulta y devolvernos un esquema completo sin tocar los datos.

En este artículo analizaremos cómo explotar esta función en entornos de consultoría reales, donde la precisión en el tipo de dato y la nulabilidad definen el éxito de un modelo de datos. Si quieres pensar como el motor de SQL Server, entender cómo se resuelven los metadatos en tiempo de compilación es el primer paso.

¿Qué es sys.dm_exec_describe_first_result_set?

Es una Dynamic Management Function (DMF) que toma una cadena de texto con código T-SQL y devuelve una tabla con la descripción de las columnas del primer conjunto de resultados que generaría dicha consulta. Lo más relevante es que no ejecuta el código; el motor realiza una resolución de nombres y tipos basándose en el catálogo del sistema.

Esta función es fundamental cuando trabajamos con herramientas que requieren una validación previa del esquema, como ocurre en la gestión proactiva de errores en Power Query o al definir estructuras de destino en un Data Lakehouse.

Sintaxis y parámetros básicos

La función requiere tres parámetros principales:

• @tsql: La consulta o lote de comandos que queremos inspeccionar.
• @params: Definición de los parámetros si el código T-SQL es parametrizado (similar a sp_executesql).
• @browse_mode: Un entero (0, 1 o 2) que determina si se incluyen columnas ocultas o metadatos adicionales para el modo de exploración.

-- Ejemplo básico de inspección de una consulta de Ventas
SELECT 
 column_ordinal,
 name,
 is_nullable,
 system_type_name,
 max_length,
 precision,
 scale
FROM sys.dm_exec_describe_first_result_set(
 N'SELECT V.Fecha, V.Importe, P.Nombre AS Producto 
 FROM FactVentas V 
 INNER JOIN DimProducto P ON V.ProductoID = P.ProductoID',
 NULL, 
 0
);

Casos de uso en proyectos de BI y DWH

En mi experiencia como consultor, el uso de esta DMF no es solo una curiosidad técnica, sino una pieza clave en la automatización. Aquí presento tres escenarios donde aporta un valor diferencial:

1. Generación automática de código (Code Generation)

Si estás construyendo una capa de staging y necesitas crear tablas que coincidan exactamente con la salida de una vista compleja, puedes usar esta función para iterar sobre los metadatos y construir un comando CREATE TABLE dinámico. Esto reduce errores humanos en la definición de longitudes de campos VARCHAR o precisiones de DECIMAL.

2. Validación de contratos en ETL

Antes de lanzar un proceso pesado de exportación de datos en SQL Server a archivos de texto, es vital confirmar que el origen no ha cambiado. Consultar esta DMF permite comparar el esquema actual con un esquema guardado en una tabla de control. Si una columna ha cambiado de nulable a no nulable, o si el tipo de dato ha variado, el proceso puede detenerse antes de corromper el destino.

3. Auditoría de linaje y tipos de datos

En sectores como el retail o la energía, donde las reglas de negocio cambian frecuentemente, es común que las columnas calculadas en SQL pierdan precisión. Esta DMF nos permite monitorizar si una columna de «Importe» ha sido degradada de MONEY a FLOAT debido a una transformación intermedia mal planteada, algo que afectaría directamente a la frescura y calidad de los datos en Microsoft Fabric.

El muro del SQL dinámico y las tablas temporales

No todo es perfecto. sys.dm_exec_describe_first_result_set tiene limitaciones severas cuando la consulta analizada no es determinista en su estructura. Si el motor no puede determinar la forma del resultado sin ejecutar el código, la función devolverá un error o una fila con valores nulos en columnas críticas.

El problema de las tablas temporales (#)

Este es el escollo más frecuente. Si tu script T-SQL crea una tabla temporal (#TempTable) y luego realiza un SELECT sobre ella, la DMF fallará. ¿Por qué? Porque la tabla temporal no existe en el catálogo hasta que el código se ejecuta realmente. Como la DMF no ejecuta el código, el análisis semántico se rompe al llegar a la referencia de la tabla inexistente.

Alternativa: Usa variables de tabla (@TableVariable). A diferencia de las tablas temporales, las variables de tabla forman parte de la declaración del lote y su estructura es conocida por el analizador en el momento de la inspección.

Ambigüedad en consultas condicionales

Si el script tiene una lógica de ramificación (IF... ELSE) que devuelve conjuntos de resultados con estructuras diferentes, la DMF intentará analizar el primer camino posible. Si las estructuras difieren, SQL Server lanzará un error indicando que no puede determinar un esquema único para el primer conjunto de resultados.

Comparativa de métodos de inspección

A continuación, comparamos las distintas formas de obtener metadatos en SQL Server para entender cuándo usar cada una:

Implementación avanzada: Manejo de errores y nulos

Cuando implementamos esta función en un entorno de producción, debemos envolverla en una lógica que gestione los casos en los que la consulta no es válida. Si pasamos un código T-SQL con un error de sintaxis a la DMF, esta no lanzará una excepción de SQL estándar, sino que devolverá un conjunto de resultados donde la columna error_number será distinto de cero.

-- Inspección avanzada con detección de errores
DECLARE @sql_test NVARCHAR(MAX) = N'SELECT ID_Cliente, Suma_Ventas FROM FactVentas WHERE Anio = 2023';

SELECT 
 name AS nombre_columna,
 system_type_name AS tipo_dato,
 is_nullable AS es_nulable,
 error_number,
 error_message
FROM sys.dm_exec_describe_first_result_set(@sql_test, NULL, 0)
WHERE error_number IS NULL; -- Solo queremos resultados si el análisis fue exitoso

Un detalle técnico crucial: la columna is_nullable es extremadamente útil para optimizar modelos en Power BI. Si sabemos que una columna de clave externa en SQL es NOT NULL, podemos confiar en que la integridad referencial a nivel de base de datos es sólida, lo que nos permite tomar decisiones de diseño más agresivas en el motor Vertipaq.

Errores frecuentes al usar la DMF

Tras años viendo implementaciones en diversos clientes, estos son los errores más comunes que deberías evitar:

• Asumir que analiza todo el script: La DMF solo describe el primer conjunto de resultados. Si tu script tiene tres SELECT, los metadatos del segundo y tercero serán ignorados.
• Ignorar el intercalado (Collation): La función devuelve información sobre la intercalación de las columnas de texto. Ignorar esto al generar tablas dinámicas puede provocar errores de «Collation mismatch» en procesos de JOIN posteriores.
• Uso de cursores o código muy complejo: Aunque la función es potente, scripts con una lógica de control de flujo muy enrevesada pueden hacer que el analizador se rinda y devuelva un error de «metadata could not be determined».
• No escapar comillas: Al pasar el código T-SQL como una cadena NVARCHAR, es vital escapar correctamente las comillas simples para evitar errores de sintaxis en el parámetro.

Checklist para el consultor de datos

1. Verifica que la consulta no dependa de tablas temporales (#). Si es así, cámbialas a variables de tabla (@) para la inspección.
2. Comprueba siempre la columna error_number en la salida de la DMF antes de procesar los metadatos.
3. Utiliza el parámetro @browse_mode = 1 si necesitas identificar qué columnas son claves primarias o forman parte de la identidad de la tabla.
4. Asegúrate de que el usuario que ejecuta la DMF tiene permisos de VIEW ANY DEFINITION o permisos específicos sobre los objetos consultados.
5. Documenta el uso de esta función en tus procesos de ETL para que otros desarrolladores entiendan que el esquema se valida dinámicamente.

Preguntas frecuentes

¿Es sys.dm_exec_describe_first_result_set más lento que ejecutar la consulta?

No, es significativamente más rápido. El motor solo realiza el análisis sintáctico y semántico (parsing y binding) sin generar un plan de ejecución completo ni acceder a las páginas de datos en disco. Es una operación de metadatos pura.

¿Puedo usarla para inspeccionar Procedimientos Almacenados?

Sí, pero con cautela. Si el procedimiento almacenado utiliza SQL dinámico internamente o tablas temporales, la DMF no podrá determinar los metadatos. En esos casos, es preferible usar sys.sp_describe_first_result_set con el nombre del procedimiento.

¿Qué diferencia hay entre esta DMF y sp_describe_first_result_set?

La funcionalidad principal es la misma. La diferencia es que sys.dm_exec_describe_first_result_set es una función de tabla que puedes usar en un SELECT (y por tanto unir con otras tablas), mientras que sp_describe_first_result_set es un procedimiento almacenado que devuelve un conjunto de resultados directamente a la aplicación.