Differences between Regular SSRS and SSRS for Dynamics AX 2012

I’ve spent quite a long time recently developing SSRS reports for Dynamics AX 2012.  In a change from AX 2009, the newer version now uses SSRS as it’s main reporting engine.  No doubt this is so that business with existing experience in the MS SQL stack can get on creating reports for their new AX 2012 installation without the need for re-training or bringing in extra people trained in X++.

So not a bad idea, however my experience has turned up a number of important differences between standard SSRS reports and those in Dynamics AX:

  • Placement of Report Code

In Dynamics AX 2012 SSRS reports you cannot use the code window found by going to the report properties.  The window is still there, and you can still type into it, but as soon as you build the report in AX the code will be stripped out of the report.  This is because when you build a report design within a Dynamics AX report model in Visual Studio, the process adds a custom code block to the report XML (a method to overwrite the report OnInit() method).  This wipes out any code you may have added.

Instead, you must add code as a new Data Method in the report model.  This can then be referenced in your report design like this: =MyMethod(arg1)

  • No ‘ResetPageNumbers’ Property on PageBreak

A great addition to SSRS 2008 was the ability to reset the page number global based on groups within your report.  This was handled by a property found by expanding out the ‘PageBreak’ property for the group.  Unfortunately this option does not exist in SSRS for Dynamics AX 2012.  There may be a good reason for this, and if anyone knows it please let me know!

To get around this I added a data method which keeps track of which group my report is on as it renders and resets the page number appropriately.

  • Conditionally Hidden Elements cause ConsumeContainerWhitespace Property to Fail

Suppose I have a one-page report that should fit onto an A4 page.  The report contains a data table and another section, which should appear at the bottom of the page regardless of the number of rows in the table.


To do this, I enclose the data table in a rectangle element which is sized such that the ‘bottom section’ is at the bottom of the page.  By setting the report property ‘consumecontainerwhitespace’ to true, I ensure that as the table grows it fills up it’s containing rectangle, but the ‘bottom section’ stays where it is.

This example would also work in AX, unless you place an element in the rectangle which can be conditionally hidden.  For example I may have a row in the table which should only be shown in certain conditions.  In standard SSRS, the report would continue to function as before, with the table consuming the rectangle and the rectangle staying the same size.  In AX however, the addition of the hidden row causes this behaviour to break and that rectangle to grow as rows are added to the table.

A workaround for this is to make the optional row ‘invisible’ by shrinking it and/or making the text and borders white so they don’t show up.