Introducción
El error ‘the key didnt match any rows’ en Power Query aparece cuando una operación de navegación o un paso posterior (por ejemplo un Merge/Expand) intenta acceder a una fila u objeto que ya no existe o no es accesible en el resultado del paso anterior. Es un problema común que detiene actualizaciones programadas y rompe pipelines que combinan archivos o usan claves fijas.
Qué es ‘the key didnt match any rows’ y por qué ocurre
Power Query representa un origen (por ejemplo un archivo Excel) con una tabla de contenidos: una lista de hojas, tablas o elementos disponibles dentro del archivo. Muchos pasos posteriores seleccionan una fila concreta en esa tabla usando claves como Item/Name, Kind o Schema. Si esa fila desaparece, se renombra, cambia su estructura o las credenciales impiden acceder a ella, la expresión M que intenta navegar devuelve el error «The key didn’t match any rows in the table».
Una analogía sencilla: imagine que la tabla de contenidos es el índice de un libro. Si el índice apunta a un capítulo que ya no existe o cambió de nombre, quien intenta abrir ese capítulo no encuentra nada.
Microsoft documenta estas causas y recomienda revisar la navegación y las credenciales como pasos iniciales de diagnóstico; su resumen técnico está disponible en la documentación de Microsoft.
Diagnóstico paso a paso
- Reproducir el error en el Editor de consultas: abra Power Query (Transform Data) en Power BI Desktop y ejecute la query para que aparezca el error; así podrá ver en qué paso sucede.
- Ir al paso Source/Navigation: en la lista de pasos, seleccione el primer paso que accede al origen (Source o Navigation). La salida previa debe mostrar la «tabla de contenidos» con columnas como Item/Name y Kind.
- Comparar la clave usada: revise la fórmula M del paso (por ejemplo
Source{[Item=...,Kind=...]}[Data]) y confirme que el valor buscado sigue existiendo en la tabla de contenidos. - Si no existe, decidir la corrección: reparar la fuente (restaurar la hoja o tabla), o editar el M para usar lógica tolerante en lugar de una referencia rígida.
- Verificar credenciales y permisos: si Desktop refresca pero el servicio falla, revise en el portal de Power BI el tipo de autenticación, credenciales y la configuración del gateway; Microsoft señala problemas por credenciales múltiples o permisos insuficientes como causas frecuentes.
Checklist para merges: preparar las claves antes de combinar
- Eliminar valores nulos o filas vacías en las columnas clave.
- Normalizar espacios y diferencias de mayúsculas/minúsculas (Text.Trim y Text.Upper/Text.Lower).
- Asegurar tipos iguales (ambas columnas como texto, número o fecha, según corresponda).
- Comprobar valores duplicados o inesperados que rompan la correspondencia.
Estos pasos reducen la probabilidad de que un Merge/Expand falle por discrepancias en las claves. La comunidad y los foros técnicos discuten estos casos con frecuencia; por ejemplo en la comunidad técnica de Microsoft se comparten soluciones y diagnósticos similares a los descritos.
Combinar archivos (From Folder) y el peligro del Sample File
Cuando Power Query usa From Folder, toma un archivo de ejemplo para definir los pasos de transformación. Si uno o varios archivos de la carpeta tienen estructura distinta (por ejemplo falta la hoja esperada o el tipo de archivo difiere), el paso definido por el archivo de ejemplo puede fallar y provocar el error. Para evitarlo, evite referencias rígidas a Item/Kind y añada lógica que omita archivos sin la hoja esperada o que valide la existencia antes de navegar.
Chris Webb explica cómo funciona este comportamiento y muestra ejemplos prácticos sobre cómo editar el paso de navegación o reforzar la lógica para que la query sea más tolerante. Consulte su explicación técnica en su blog para ver ejemplos concretos: guía de Chris Webb.
Diferencias entre Desktop y Power BI Service
Es habitual que una consulta refresque sin errores en Power BI Desktop pero falle en el servicio. Las razones más comunes son:
- El servicio puede ejecutar el refresco de datos sin volver a evaluar el esquema exactamente como lo hace Desktop durante la depuración.
- Problemas de credenciales o configuraciones del gateway que impiden acceder a ciertos objetos desde el servicio.
Revisar el historial de refresh y la configuración de fuentes en el servicio ayuda a identificar si el problema es de acceso o de estructura.
Patrón M tolerante: verificar existencia antes de seleccionar
En lugar de usar una selección rígida como Source{[Item="Hoja1",Kind="Sheet"]}[Data], se recomienda comprobar primero si la fila existe y actuar en consecuencia usando Table.SelectRows o condicionales. La idea general es:
- Obtener la tabla de contenidos del origen.
- Filtrar por la fila que interesa con
Table.SelectRowso similar. - Si el resultado está vacío, tomar una ruta alternativa (por ejemplo registrar el archivo y continuar); si no, navegar al
Data.
Este enfoque hace que las combinaciones From Folder y las referencias a hojas sean más robustas frente a cambios en archivos y evita que aparezca el error ‘the key didnt match any rows’ cuando un elemento falta o cambia.
Qué revisar primero (resumen rápido)
- Source/Navigation: ¿sigue existiendo la fila clave?
- Credenciales y gateway: ¿el servicio tiene permisos equivalentes a Desktop?
- Claves para Merge: tipos, nulos, espacios, case.
- Combinar archivos: evitar dependencias en el Sample File sin validaciones.
El error ‘the key didnt match any rows’ es frecuente pero, por fortuna, suele resolverse con un diagnóstico directo y cambios relativamente simples: revisar el paso de navegación, normalizar claves antes de merges y asegurar permisos en el servicio. Mantener queries tolerantes y validar la existencia de las filas esperadas reduce significativamente interrupciones en pipelines críticos.
Para referencias técnicas y ejemplos más detallados, consulte la documentación de Microsoft, la explicación paso a paso de Chris Webb y los hilos de la comunidad técnica de Microsoft y Stack Overflow listados entre las fuentes.