none
Informe de tipo Maestro-Detalle

    Question

  • Hola,

    Tenemos diseñado un informe de tipo Maestro-Detalle que muestra una lista de pedidos y sus líneas de detalle (artículos incluidos en el pedido). Estas líneas de detalle las mostramos con un subinforme. Así conseguimos sacar toda la información que necesitamos, pero el rendimiento del informe es pésimo, de 2 a 3 minutos para mostrar en pantalla 4 pedidos con 6 líneas cada pedido. Pensamos que esto se deba a que estamos utilizando un subinforme para mostrar las líneas.

    ¿Cómo podríamos hacer un informe Maestro-Detalle sin usar un subinforme?

    Si no es posible, ¿cómo podríamos mejorar el rendimiento?

     

    Tuesday, November 08, 2011 5:54 PM

Answers

  • ¿Y cómo sabes que es por eso? Tal vez sea por las consultas que se realizan para extraer los datos, porque usas algunas funciones que ralentizan el renderizado del informe, por... pueden ser por multitud de razones.

    En http://blogs.msdn.com/b/robertbruckner/archive/2009/01/05/executionlog2-view.aspx se explica cómo analizar el rendimiento de un informe para tratar de mejorar su tiempo de respuesta. Creo que merece la pena echarle un vistazo

    • Marked as answer by Copermatica SL Wednesday, November 16, 2011 3:41 PM
    Thursday, November 10, 2011 10:35 AM
  • Efectivamente los subinformes suelen tener un rendimiento relativamente pobre, pero 2 a 3 minutos para presentar 4 pedidos con 6 líneas es excesivo. Tiene que haber algún otro tipo de problema.

    En cualquier caso, si lo que quieres es sacar el maestro-detalle sin subinformes, lo que se hace es anidar dos regiones de datos. En esta dirección: http://gotreportviewer.com/masterdetail/index.html tienes un ejemplo que enseña el mismo informe construído primero con subinformes, y después con regiones anidadas.

     

    • Marked as answer by Copermatica SL Wednesday, November 16, 2011 3:41 PM
    Thursday, November 10, 2011 2:09 PM
    Moderator

All replies

  • ¿Y cómo sabes que es por eso? Tal vez sea por las consultas que se realizan para extraer los datos, porque usas algunas funciones que ralentizan el renderizado del informe, por... pueden ser por multitud de razones.

    En http://blogs.msdn.com/b/robertbruckner/archive/2009/01/05/executionlog2-view.aspx se explica cómo analizar el rendimiento de un informe para tratar de mejorar su tiempo de respuesta. Creo que merece la pena echarle un vistazo

    • Marked as answer by Copermatica SL Wednesday, November 16, 2011 3:41 PM
    Thursday, November 10, 2011 10:35 AM
  • Efectivamente los subinformes suelen tener un rendimiento relativamente pobre, pero 2 a 3 minutos para presentar 4 pedidos con 6 líneas es excesivo. Tiene que haber algún otro tipo de problema.

    En cualquier caso, si lo que quieres es sacar el maestro-detalle sin subinformes, lo que se hace es anidar dos regiones de datos. En esta dirección: http://gotreportviewer.com/masterdetail/index.html tienes un ejemplo que enseña el mismo informe construído primero con subinformes, y después con regiones anidadas.

     

    • Marked as answer by Copermatica SL Wednesday, November 16, 2011 3:41 PM
    Thursday, November 10, 2011 2:09 PM
    Moderator
  • En primer lugar, agradeceros a los 2 las respuestas en tan corto plazo de tiempo. Y comentaros que gracias a la información proporcionada por ambos, hemos conseguido mejorar con creces el rendimiento del informe.

    En un principio, pensábamos que principalmente era problema de las llamadas al subinforme, cosa en la que no íbamos mal encaminados, sólo hay que ver el ejemplo que indica Alberto para ver la diferencia entre diseñarlo con un subinforme o no (justo esto es lo que necesitábamos). Pero además, y como bien indica Carlos, se debía a la consulta, y más concretamente a la definición de los Filtros. El diseño del informe lo hacemos desde la herramienta Report Builder 3.0 de SQL Server, y ocurría que estábamos creando los filtros desde la pantalla de Propiedades del Conjunto de Datos (fallo nuestro porque pensábamos que estos filtros se aplicaban en la consulta), en lugar de hacerlo desde el Diseñador de Consultas. De esta manera, nos estábamos trayendo toda la información, y después se estaban aplicando los filtros.

    Al hacerlo desde el Diseñador de Consultas:

    te monta la cláusula WHERE en la Consulta, sin necesidad además de editarla manualmente (también crea automáticamente los parámetros necesarios en el informe), lo que le da toda la potencia a la Consulta y, en consecuencia, aumenta el rendimiento del informe.

    Ahora funciona de forma muy óptima.

    Muchas gracias.

    Wednesday, November 16, 2011 3:40 PM