web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics AX (Archived)

SSRS Performance is slow using data provider

(0) ShareShare
ReportReport
Posted on by 1,673

Hi Everyone

I would like to know if there is a simple way to enhance the performance on an SSRS report that uses a data provider, and heaps of data, (say anything between 300 000  and a million records that get written to the temp table). Some of the data is retrieved from display methods.

I have this scenario:

Table a;

while select a

{

tmp.field1 = a.field1;

tmp.field2 = a.getValue();

tmp.insert();

}

while select b

{

tmp.field1 = b.field1;

tmp.field2 = b.getValue();

tmp.insert();

}

Here is what I've discovered and tried:

- if the resulting tmp table gets over 300000 records inserted into it, it is the insert() part that slows everything down

- I tried to use a RecordInsertList but it doesn't appear to work on tmp tables (correct me if i'm wrong)

- I thought of trying to use insert_recordset, but I can't get around the display methods (I HAVE to use display methods)

- I'm trying to build one query now that consists of table A, and table B. The problem with this though is that on the report, I can't just reference 'field2' which I would do if I were using a temp table. Now I have to somehow reference a.getValue and b.getValue on the report itself, consolidated into 1 field

- My next thought was to use a union query (with field2) consisting of a view made from table A, and a view from table B (table A and table B do NOT have the same structure), but using a view like this means that I'd have to use a computed column to retrieve the values in getValue in each table, which pushes the sql calls up again, which slows the report down again.

Is there a simple way to do this that I'm missing? (Hope my explanation isn't too confusing)

Thank you!

*This post is locked for comments

I have the same question (0)
  • Martin Dráb Profile Picture
    237,904 Most Valuable Professional on at

    There surely will be opportunities for optimization.

    First of all, do you really print 300 000 records in your report? Or does it mean that there are more inserts than actually needed?

    You rarely have to use display methods - it usually means that you consider display methods the most appropriate technique for the given scenario. If no other solution is possible (such as rewriting display methods to queries or computed columns), you can always keep pre-calculated values in database, for instance.

  • Mea_ Profile Picture
    60,284 on at

    Hi BrandonSA,

    You can use set-based insert with  Query::insert_recordset(), however, you need to get rid of display method.  There is a good blog series from Perf team regarding SSRS performance where you can find details about Query::insert_recordset() and other tricks blogs.msdn.microsoft.com/.../ssrs

  • BrandonSA Profile Picture
    1,673 on at

    Hi

    Thanks for the replies gentlemen.

    Here are a few other facts about this report:

    - I don't display 300000 records on the report; the report only displays about 1 or 2 pages of pivoted data made up of about 300000 records

    - the display method is necessary. It takes sensitive encrypted data (numeric) that can't be stored openly on tables, decrypts it, and writes it to the tmp table. Therefore, I can't use aggregate functions on the data that this particular display method returns because it first has to be decrypted. Nor can I save it before hand in any pre-prossessed tables because that would expose them. It also means as far as I can see that I can't do any of the pivoting functionality on the Ax side.

    Martin, you said I might be able to use computed columns. I presume you mean on views? If that's the case, I did think about using that, but doesn't that come down to the same thing? Is there a difference between the performance of a display method and a computed column?

    Thanks

  • Martin Dráb Profile Picture
    237,904 Most Valuable Professional on at

    If you say that the problem is in inserting a huge amount of records and you're saying that they're not actually needed, I believe you should redesign your solution. The problem isn't in the report requiring huge amount of data, it's in the way you prepare the data. You found it causes performance problems, so it's time to change it.

    Computed columns are *much* faster. If you get thousand records with a computed column, you make a single query to database and get all data at once (SQL Server will just execute a piece of SQL code to compute computed columns). If you use a display method, you'll get your records and then call the method thousand times. If it makes even a single DB call, you may end up with extra 1000 calls to database, which it why it will be several orders of magnitude slower.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
Martin Dráb Profile Picture

Martin Dráb 4 Most Valuable Professional

#1
Priya_K Profile Picture

Priya_K 4

#3
MyDynamicsNAV Profile Picture

MyDynamicsNAV 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans