RDLC report with large datasets

Alex_Chow

Hi Guys,

So does anyone have a solution for reports running in NAV2013 with a large dataset?

For example, A/R (and A/P) report with detail, inventory valuation, etc.

If there is too much data, RDLC crashes.

Any solutions to this without writing an export to Excel? Or other work arounds?

Torben_Wind_Meyhoff[MSFT]

Hi Alex

When you run these reports from the Windows Client, the data set and RDLC is send to the client and there combined.
Windows Client is 32 bit and as you mention, if the report has to many details, you run out of memory.

The easiest workaround is to run the report with C/AL Report.SaveAsPdf(...) (Request Page Save to PDF is client side rendered). This will do the rendering on the server side which runs 64 bit and can handle much larger reports. I have done tests utilizing more than 40 Gb of memory.
If you don't like the PDF intermediate step, then consider Report.RUN from within STARTSESSION (Documented as Print On Server), which is also a pure server side operation.

There is also a hotfix that removes a performance regression introduced in the combination of Report Viewer 2010 and .NET 4 (Look for New Information since Update Rollup 5: update to the hotfix and add NetFx40_LegacySecurityPolicy to the config files)
http://blogs.msdn.com/b/nav/archive/201 ... eview.aspx

Duilio Tacconi made a very good post about this topic in general:
http://blogs.msdn.com/b/nav/archive/201 ... s-nav.aspx

BR
Torben

Alex_Chow

Like I said, no work arounds. When the customer buys this product, they expect it to work out of the box.

And there's no way for us to tell which report will run into this problem. The "sometimes it will work and sometimes it will not" will not fly with customers.

ara3n

Here is AR Report on SQL

http://mibuso.com/blogs/ara3n/2014/07/0 ... amics-nav/


And AP Report on SQL

http://mibuso.com/blogs/ara3n/2014/07/0 ... amics-nav/

sendit2jason

If it's worth any comfort we have encountered this issue with a few NAV2013 R1 and R2 clients. Really annoying especially if the Reports are NAV standard. However, with document outputs like Statements and Invoices the logo will gobble up memory quickly. There is a work around in code to clear the Picture flowfield after the header line has been retrieved.

I also try to keep my dataset small and remove unused columns.

The other option is server side printing which was already mentioned here, but I'm too familiar with that as yet.

ara3n

Something else that can be done as well is that all the decimal values have two column, one for formatting and one for the value.

In NAV 2013, you can change them to string using format and it have one column instead of two, but it's still workaround.

Alex_Chow

Alex Chow wrote:

Like I said, no work arounds. When the customer buys this product, they expect it to work out of the box.

And there's no way for us to tell which report will run into this problem. The "sometimes it will work and sometimes it will not" will not fly with customers.

When you have clients that upgrades thinking they have the latest and greatest, you're telling me that I have to tell them that we will need additional billable hour to address something that should've not been a issue at all?

This is quite embarrassing to say the least and kills our credibility.

jglathe

Spot on.

davmac1

I had a customer over 10 years ago who switched from his nice customized Cobol based package to Oracle Financials and Manufacturing and spent million of dollars in customization and still did not get all the features of their old package.
I would have got into NAV far earlier than I did if I had not wasted my time looking for the perfect package.

If you find one, let us know.

Alex_Chow

davmac1 wrote:

I had a customer over 10 years ago who switched from his nice customized Cobol based package to Oracle Financials and Manufacturing and spent million of dollars in customization and still did not get all the features of their old package.
I would have got into NAV far earlier than I did if I had not wasted my time looking for the perfect package.

If you find one, let us know.

:shock: :shock: :shock: I don't even know how to respond to this.

So what are you saying? Just shut up and accept it the way it is?

davmac1

What I am saying is all software packages I have experience with have problems. Some worse than others.

It would be nice if Microsoft could put some qualified people on report development.
It would also be nice if they did not remove a feature that 99% of its partners and developers used, then finally put it back in a form that only 10 to 20% can use.

And now upgrades are going to be easy. I can hardly wait. I am expecting it to require a new way of doing mods, which would do no good for existing NAV implementations.