Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

We've captured the moments from FabCon & SQLCon that everyone is talking about, and we are bringing them to the community, live and on-demand. Starts on April 14th. Register now

Reply
Syndicate_Admin
Administrator
Administrator

rsQueryTimeoutExceeded

Hola

Estoy experimentando un problema crítico de rendimiento y agotamiento de recursos al intentar forzar el uso de una relación inactiva en una medida DAX para la facturación. El objetivo es que los filtros de fecha afecten a la fecha de factura y no a la fecha de admisión, que es la relación activa predeterminada.

Contexto del modelo de datos:

Tengo un modelo con tres tablas clave:

  1. Calendario (Date Dimension Table): Contains the FechaFactura column (Date).

  2. HOSMA_Negocio (Tabla de datos de admisión): Contiene la columna Fecha (Fecha de admisión).

  3. HOSMA_LineasFactura (Tabla de hechos de líneas de factura): Contiene la columna FechaFactura (Fecha de factura).

Relaciones de tabla:

  • Calendario[FechaFactura] (1) <-- (M) HOSMA_Negocio[Fecha] --> ACTIVE Relationship.

  • Calendario[FechaFactura] (1) <-- (M) HOSMA_LineasFactura[FechaFactura] --> INACTIVE Relationship.

  • Ambas tablas de hechos (HOSMA_Negocio y HOSMA_LineasFactura) están relacionadas entre sí a través del campo IdEpisodio_TipoEA (Uno a varios).

Medida DAX problemática:

Para cambiar el contexto de fecha a la fecha de factura, estoy usando USERELATIONSHIP:

Facturacion = CALCULATE( COALESCE(SUM(HOSMA_LineasFactura[Importe_Rentabilidad]), 0), USERELATIONSHIP(HOSMA_LineasFactura[FechaFactura], Calendario[FechaFactura]) )

Problema y errores:

Al usar esta medida en cualquier objeto visual que implique filtros de la tabla Calendario, los objetos visuales no se cargan y obtengo los siguientes errores (incluso después de simplificar las tablas):

  1. En Power BI Desktop:

Error al recuperar datos para este objeto visual. No hay suficiente memoria para completar esta operación. Vuelva a intentarlo más tarde cuando haya más memoria disponible.

  1. En el servicio Power BI (Web):

Recursos excedidos. La consulta superó los recursos disponibles. Intente filtrar para reducir la cantidad de datos solicitados.

  • Error subyacente: rsQueryTimeoutExceeded

  • Detalles: se agotó el tiempo de espera de la solicitud XML para análisis antes de completarse. Valor de tiempo de espera: 225 s.

Lo que ya he probado:

  • Simplificar el modelo y eliminar columnas innecesarias.

  • Reducir la granularidad de los objetos visuales (agregar por mes en lugar de por día).

Pregunta:

¿Es esto un síntoma de un modelo de datos defectuoso debido a que tiene dos posibles rutas de fecha? ¿Existe un patrón DAX más eficaz para controlar esta transición de contexto o es la única solución sólida para duplicar la tabla Calendario y crear dos relaciones activas independientes?

Cualquier sugerencia para optimizar el modelo o el DAX es muy apreciada. ¡Gracias de antemano por su ayuda!

6 REPLIES 6
Syndicate_Admin
Administrator
Administrator

@jesushmmadrid

¿Puedo comprobar si este problema se ha resuelto? Si no es así, no dudes en contactarnos si tienes más preguntas.


Gracias

Syndicate_Admin
Administrator
Administrator

Hola a todos,

Muchas gracias por todas tus sugerencias. He probado las soluciones recomendadas, incluyendo usar dos tablas de fechas separadas y reemplazar USERELATIONSHIP por TREATAS, pero el problema sigue persistiendo y sigo cumpliendo con los límites de recursos.

Lo que he probado:
1. Crear dos tablas de fechas separadas (AdmissionDate y InvoiceDate).
Esto mejoró el rendimiento, pero creó un problema diferente. Varias páginas de informe combinan métricas tanto de HOSMA_Negocio como de HOSMA_LineasFactura usando los mismos segmentadores de fecha. Con dos tablas de fechas, los segmentadores solo filtran una tabla de hechos a menos que introduzca relaciones bidireccionales o tablas puente, lo que causa ambigüedad y problemas de rendimiento. Como resultado, los números entre negocio y facturación ya no coinciden.
2. Sustituir la relación de uso por TREATAS.
Esto reduce la carga, pero sigo teniendo tiempos de espera al filtrar grandes intervalos de fechas. Creo que el camino indirecto a través de IdEpisodio_TipoEA fuerza a contextos de filtro muy grandes.
3. Simplificar el modelo y reducir columnas.
Incluso con estas optimizaciones, los gráficos pesados siguen fallando.

Sobre lo que necesito aclaraciones:

El principal reto parece ser que ambas tablas de hechos están conectadas a través de IdEpisodio_TipoEA y se usan juntas en varias páginas de informes. Necesito que ambas tablas de hechos se filtren de forma consistente, pero las medidas de facturación deben usar un contexto de fecha diferente, sin romper páginas existentes ni duplicar el modelo por completo.

Antes de reestructurar todo el modelo, me gustaría preguntar:

¿Existe algún patrón recomendado para escenarios en los que dos tablas de hechos están conectadas, ambas necesitan un filtrado consistente en algunas páginas, pero un subconjunto de medidas debe usar una ruta de fechas diferente?

¿Sería más apropiado un grupo de cálculo, una tabla de fechas desconectada con TREATAS o un patrón de modelo compuesto?

Agradezco cualquier orientación adicional. Es un escenario complejo y me gustaría evitar romper la lógica existente de los informes.

Gracias de nuevo por tu ayuda.

@jesushmmadrid ,

Usar un Modelo Compuesto puede ayudar sin duda a separar la lógica de fechas manteniendo ambas tablas de hechos consistentemente filtrables, y aplicar patrones de grupo por / resumir en medidas clave también puede reducir el tamaño del contexto del filtro y mejorar el rendimiento.

Por favor, sigue estos artículos para referencia:
Guía de optimización para Power BI - Power BI | Microsoft Learn

Técnicas de reducción de datos para modelado de importación - Power BI | Microsoft Learn

Técnicas de reducción de datos para modelado de importación - Power BI | Microsoft Learn

Saludos

Syndicate_Admin
Administrator
Administrator

Hola @jesushmmadrid

Quería comprobar si tuviste la oportunidad de revisar la información proporcionada. No dudes en ponerte en contacto con nosotros si tienes más preguntas.


Gracias.

Syndicate_Admin
Administrator
Administrator

Esto sucede porque USERELATIONSHIP sobre dos tablas de hechos y una ruta indirecta obliga al motor a evaluar un contexto de filtro enorme.

La solución limpia es crear dos tablas de fechas de juego de roles, una para Admisión y otra para Factura, cada una con una relación activa.

Eso elimina la ambigüedad y hace que DAX sea mucho más rápido. Si los cambios de modelo no son posibles, pruebe TREATAS en lugar de USERELATIONSHIP , generalmente es más ligero en recursos.

Shai Karmani | Datos y análisis

Si ayudaba,

Por favor, marque como resuelto y dé un kudo para que otros también puedan encontrarlo.

Conectémonos en LinkedIn

Syndicate_Admin
Administrator
Administrator

Hola @jesushmmadrid

Su problema proviene de tener dos rutas de fecha, la función USERELATIONSHIP hace que el motor trabaje demasiado, lo que provoca tiempos de espera.

Sugiero un par de opciones para resolverlo:

  • La mejor opción → usar dos tablas de fechas separadas (una para Admisión y otra para Factura).

  • O reemplace USERELATIONSHIP con TREATAS, que es más ligero.

  • Compruebe también los filtros cruzados entre las tablas de hechos y las líneas de factura agregadas previamente si son demasiado detalladas.

¿Funcionó? 👍 Se agradecería un elogio
🟨 Márquelo como una solución para ayudar a difundir el conocimiento 💡

🟩 Sígueme en LinkedIn

Helpful resources

Announcements
New to Fabric survey Carousel

New to Fabric Survey

If you have recently started exploring Fabric, we'd love to hear how it's going. Your feedback can help with product improvements.

Power BI DataViz World Championships carousel

Power BI DataViz World Championships - June 2026

A new Power BI DataViz World Championship is coming this June! Don't miss out on submitting your entry.

Join our Fabric User Panel

Join our Fabric User Panel

Share feedback directly with Fabric product managers, participate in targeted research studies and influence the Fabric roadmap.

March Power BI Update Carousel

Power BI Community Update - March 2026

Check out the March 2026 Power BI update to learn about new features.

Top Kudoed Authors