Very slow load times when using .canGrow and .canShrink with PageReport

Posted by: david.thompson on 14 May 2018, 9:02 am EST

    • Post Options:
    • Link

    Posted 14 May 2018, 9:02 am EST

    Environment: Windows Server 2008

    Data Source: <Seems to be arbitrary … but currently using MySQL>

    Report Type: PageReport using FixedPage > Page > Containers > Table > Table Row > Table Cell

    The report is built dynamically in VB (.net 4.5) based on user input and user selections. So I don’t have an rdlx file but I could save one from the code if necessary.

    As the title suggests, I’m having an extremely slow load time when using .canGrow and .canShrink on textboxes contained within tablecells in a page report. Without the .canShrink and .canGrow properties enabled the report loads in a matter of seconds.

    I’m trying to get empty rows to disappear and large rows to expand … which I would imagine is pretty common. The only table in the report has 10 columns with plain text values.

    The issue is more noticeable as the size of the dataset increases. I suspect that is due to the amount of calculations happening to space things out appropriately.

  • Posted 14 May 2018, 9:03 am EST

    I forgot to mention. I’m using AR 12 SP1 devloper (Just updated to the latest today to make sure it wasn’t already corrected).

  • Posted 14 May 2018, 6:17 pm EST

    Hello David,

    You cannot use the “CanGrow” and “CanShrink” property of “TextBox” for “PageReport”. Size of controls in PageReport never changed at runtime. To achieve the same you can use the “RDLReport” report to change the size of “TextBox” as per content.

    Hope it clarifies.

    Thanks,

    Mohit

  • Posted 15 May 2018, 1:58 am EST

    Mohit,

    I hate to differ with you, but I did use .canGrow and .canShrink with several textboxes in a PageReport. And it works (at least for me it does) … it is just slow.

    I’ll look into seeing if I can use the RDLReport report instead

    Thank you for the quick reply!

  • Posted 15 May 2018, 2:01 am EST

    Also, I’m not sure if it makes a difference, but I’m building this report outside of the designer. When I say I’m using a PageReport, I mean I’m using the PageReport class in .NET

  • Posted 15 May 2018, 2:01 am EST

    Also, I’m not sure if it makes a difference, but I’m building this report outside of the designer. When I say I’m using a PageReport, I mean I’m using the PageReport class in .NET

  • Posted 15 May 2018, 8:45 pm EST

    Hello David,

    Both RDL and Page Report use the same “PageReport” class. When you use the “FixedPage” in “PageReport” class then it becomes the Page report. Due to “FixedPage”, the controls remain fixed at runtime, hence there is no effect of “CanGrow” and “CanShrink” property. You are using “RDL report” earlier where “CanGrow” and “CanShrink” property works.

    Also, I have tested with RDL report at my end. I observe the difference of loading time when “CanGrow” set to True. However, there is a lot of difference of page number in both time

    When CanGrow True: 100000+

    When CanGrow False: 3100+

    Hence, difference in load time is by design because the difference of page number in both times is very large.

    Could you please share the page number of the report in both cases. Also, please share the load time in both cases.

    Thanks,

    Mohit

  • Posted 16 May 2018, 1:59 am EST

    Hi Mohit,

    I had to reduce my dataset significantly, normally I would’ve had over 6000 pages and the load times took over 15 minutes to load… So I reduced my dataset, and here are my initial findings

    .cangrow = True - 154 pages, 45 second load time

    .cangrow = False - 133 pages, 35 second load time

    I found one other dynamic component that made a drastic difference. I’m using a tablegroup footer that has .PrintAtBottom = True

    .cangrow = True, footer using .PrintAtBottom = True, 154 pages, 45 second load time

    .cangrow = True, footer using .PrintAtBottom = False, 154 pages, 4 second load time

    .cangrow = False, footer using .PrintAtBottom = False, 154 pages, 1 second load time

    It is worth noting, the only thing I have in the tablegroup footer is the pagenumbers and a date (output as a string)

  • Posted 16 May 2018, 9:37 pm EST

    Hello David,

    I can observe the difference between the load time when PrintAtBottom is “True” and “False”. In my understanding, report takes more time to load when “PrintAtBottom” is True because it calculates the PageEnd at every page.

    However for more detail, could you please share your sample application with the database which demonstrates the same. So that I can share with our developer team and they will provide you solution according to your use case.

    Thanks,

    Mohit

  • Posted 17 May 2018, 1:06 am EST

    Hi Mohit,

    I can provide you some sample code, and a sample data source (that will be built into the code) … the real database is full of sensitive information. It’ll take me a little bit to package that up and send it your way but I should be able to get something sent your way.

  • Posted 17 May 2018, 1:52 am EST

    Hello David,

    Currently, you can send the sample code with sample data. We can tell you if we need anything further.

    Thanks,

    Mohit

  • Posted 17 May 2018, 3:49 am EST

    Hi Mohit,

    I’ve attached the sample code . Let me know if anything else is needed !

    Thank you!

  • Posted 17 May 2018, 3:51 am EST

    I didn’t see the attachment show up… Trying again

    ar_sample_site.zip

  • Posted 17 May 2018, 8:18 pm EST

    Hello David,

    Thanks for the sample.

    I am able to replicate the problem at our end. I have escalated this to the development team(Tracking ID 257456) and will revert you back once have any information from them.

    However, as a workaround, you can add the Table Inside the container and put two textboxes (instead of GroupFooter) after fixed size of table to show page number and date.

    Thanks

    Mohit

  • Posted 18 May 2018, 2:24 am EST

    Hi Mohit,

    We’ll give your suggestion a shot. I’m a bit apprehensive as the date being displayed is derived from the data in the detail section (we’re grouping by date ranges) so I’m not entirely sure if that will work but we’ll take a look.

    Thanks for the update!

  • Posted 20 May 2018, 9:39 pm EST

    Hello David,

    Yes, If the date is derived from the detail section, then the above workaround is not worked.

    Also, your issue is with our developer team and will update you once I get any information.

    Thanks,

    Mohit

  • Posted 12 June 2018, 4:15 pm EST

    Hello David,

    Issue is fixed in our internal build. Do you need hotfix for the same?

    Thanks,

    Mohit

  • Posted 13 June 2018, 3:18 am EST

    Hi Mohit,

    We would love a hotfix if it is available, thanks for the follow up!

    -Dave

  • Posted 14 June 2018, 3:57 pm EST

    Hello David,

    I have send your request to our development team.

    Thanks,

    Mohit

  • Posted 14 June 2018, 7:17 pm EST

    Hello,

    Please refer the following link to download the installer of latest hotfix:http://cdn.grapecity.com/ActiveReports/ar12/hotfixes/ActiveReports-v12.1.13538.0.msi

    Hope it resolves your issue.

    Thanks,

    Mohit

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels