NAV Team: Designing reports for better performance on RTC

[Blog bot]

Some of you might have run into scenarios that a report that runs for some (acceptable) time on classic client takes far longer time on RTC or simply even errors out with OutOfMemory kind of exception.

Some have also asked what the limitation to number of records sent to RTC is, when experiencing this. Well, my personal environment here shows that 250.000 records will transfer, but the report will be left running for a long, long time. Far longer then the classic equivalent, which finished in say 15 minutes. So how to deal with this?

Well while as sending 250.000 rows (which equivalents to about 11.000 output pages!!!) is quite an amount of data to print, and one might assume that not too many people would want to print this much in the first place, you might not be aware your'e sending this many records, as your output may come down to mere 2 pages. So this is a blog for that kind of reports, reports that will process many rows, but really do output realtively little (and by relatively little, i mean anything under couple of hundred of pages).

Lets start by looking into what is sent to RTC. We have sections that are data containers for RDLC reports, so all data contained there would naturally be sent to RTC. But not only that! To see what's sent to RTC, look at your report metadata (export the metadata blob and save it as an xml file to check this). What you might not be aware of is that all records within metadata are sent. And metadata is really your report structure.So if your report has 3 data items, all records processed within filtered selection, that belong to those data items, will be sent to RTC. Which is why you might find out that some report run for a long time (after sending dusins and hundreds of thousand of rows), but output only few pages, or in any case far less then the amount of records processed. This mostly happens with reports that:

1 Use data items for calculation and not necessarilly output records from these in printout (data items not used in sections at all)

2 Use dataitems for footers and headers only (data items not used in body type of sections)

3 Have 'PrintDetails' option (data item IS used in body section) which again means that regardless of the fact your user hasn't opted to print details, that data item is in the report structure hence all those records are sent to RTC anyway.

So these are the things you want to watch out for if you are writing your reports for RTC.

In case of 1. => do the calculation in the code instead of in report dataitems (repeat.. until indented loops will result in same calculation as two indented items, provided adequate sorting and filtering is added to the code). This will process same amount of records in same time, it will only result in being able to remove dataitems from report structure, and that itself will cut down on the number of records being sent to RTC considerably in some scenarios.

In case of 2. => Don't! Using data item will send all records within filtered selection, so if you only want to print footer of a group of value entries (and don't have a body section for that data item at all), you will end up sending all these value entries to RTC, which in most installtions is a lot.Use an integer data item to output the footer once per group instead, handle the summarizing of values within the group, in the code instead.

In case of 3. => Well here you can't just replace the body of the section in a simple way. But you can have two reports instead. Detailed one will remain as it is (naturally, remove all sections/items that print on NOT printdetails), but here it is maybe safe to assume that most customers will not often opt to send 10.000 pages of detailed entries to output? But rather filter on smaller selections. And then the not-detailed report that they want to run and look at summary values for bigger range of data, rather then all details: here, remove detailed sections (meaning: remove data items belonging to detailing section and handle all data processing for calculation and totalling in the code instead of through data items), and that way you can process millions of records and output few pages, running in exactly the same time on RTC as you do on classic client.

As a test, I've done it on couple of standard reports that process a lot and tested their running time after modifications. And as assumed, millions of records process and the few pages are printed in 15 minutes, even on RTC :-)

I wasn't quite aware of this before and I hope this might be of some use to those of you that weren't aware of this either.





Источник: http://feedproxy.google.com/~r/Micro...ce-on-rtc.aspx