When it comes to designing RDL reports in Microsoft Dynamics NAV / Business Central, there are three different programs which you can use:

• Visual Studio
• Report Builder
• Word

Especially as a beginner you will be confronted with a decision between these two fellas: Visual Studio 2017 or Report Builder 2016?

Layouts created with Microsoft Word have the file extension .docx. They differ greatly from layouts generated by Microsoft Report Builder (.rdl) and Microsoft Visual Studio (.rdlc). For this reason, I will exclude word layouts from this post and cover them in a later post (or never, as I truly despise them at times).

RDLC and RDL

RDLC means Report Definition Language Client-side. As the name already suggests, RDLC reports are executed on the client. RDL Reports on the other hand are executed on a server. I will not go more into detail here because I do not want to lose you to the confusion train.

RDL Reports and RDLC Reports look the same. If I create a report with the file extension .rdlc, I can open it with Visual Studio. Change the file extension from “.rdlc” to “.rdl” and you can open it with Report Builder.

In the below example I downloaded the standard .rdl layout from the custom report selection in business central. It displays the list of customers. This is how it looks when you print it:

I downloaded the .rdl file with the “Custom Report Layouts” page.

“R101_CustomerList.rdl” is the file I downloaded. If I make a right click and choose “Open Externally”, Report Builder opens.

Right click on the .rdl file and choose “Open Externally”.

See wonderful layout in Report Builder:

The file “R101_CustomerList.rdlc” is a copy of the file “R101_CustomerList.rdl”. The only thing I changed is the file extension so I can open it in Visual Studio.

Right click on the file -> “Open Externally”.

Layout in Visual Studio:

Visual Studio or Report Builder – Which Is Better for RDL Reports?

“So it is kind of the same, but not the same, right?” Well yea, kind of. It is hard to tell which of the tools is better in general. They are different. I guess the more experienced you are, the more you will tend to use Visual Studio instead of Report Builder. To decide which one suits your needs the best, it is good to know the differences between the tools.

Document Outline

If there is one big reason to choose Visual Studio, then it is probably this one. Visual Studio offers you the possibility to see the hierarchy of the report controls.

“I have no idea what you are talking about. Pics plz.”

Okay. So, what the heck does that mean? Let’s look at a familiar example. This is the .rdlc design of a Sales Invoice (Standard report 1306).

If your Document Outline is not visible when you open Visual Studio, try the shortcut Ctrl + Alt + T. It opens the Document Outline on the left. I love it.

It shows me the hierarchy of the report with the parent-child relationships between the controls.

If I click on a control in the Document Outline, the control is highlighted in the design on the right side (the red borders are mine, the highlighting done by Visual Studio is a bit more subtle).

This has always been the reason for me to use Visual Studio when designing complex reports like purchase orders or sales invoices. If a report reaches a complexity where you have multiple parent-child relationships between your controls and some rectangles or tables, then you should think about switching to Visual Studio.

Why is that? Well. Designing reports can get quite messy. If you move your rectangles, tables and textboxes around in your layout, you can unattentionally cause unwanted behaviors of your report. It is pretty easy to turn a well structured and wonderful report into the longterm object of your nightmares.

One thing to mention though: the document hierarchy can slow down the performance of Visual Studio a bit. If you keep it open all the time, everytime you move controls around or change/delete them, it will refresh. The more controls your report contains, the more likely you will have to wait a little moment until Visual Studio is ready for user interaction again. It might be a good idea to keep it closed for situations where you do not necessarily need it.

Aligning Tools

Designing Reports is a lot of dragging and dropping controls from point a to point b. Let’s be honest. Even a monkey could so some tasks that are involved when creating reports. To keep the structure clean and pretty, you sometimes want to remove the spacing between controls. Other times you will want to align controls to the same width, height, or specific positions.

This is where the aligning tools come into play. It is an awesome feature available in Visual Studio. On opening Visual Studio for the first time, they are not visible, but you can easily make them visible as I show you in this post.

The screenshot below shows the functions that I use frequently to design faster.

If you have never used them, you probably think you do not need them. Trust me in this thing: Once you use them, you will never want to give them back again!

Using the aligning tools

Let’s take our Customer List Report again. We want to move our COMPANYNAME from the left to the right.

First I press the left mouse button and mark the three controls on the top right, then I press CTRL and left click on the COMPANYNAME as well. All four controls are marked.

Now align it to the right.

Still a bit messy. Now Remove vertical spacing and we are done:

Before aligning it to the right, we could have also used the “Make some Width” button so that all controls would have the same size in the end.

This is way less error-prone than moving controls manually. Also, it is better for your nerves, trust me in this one.

XML Search

One cool feature that Visual Studio offers is the possibility to change the XML file itself instead of the design. This opens great opportunities. If you decide that you do not like the font Segoe UI and instead would like to use Arial in your hole document, you can simply replace all the instances of Segoe UI in your XML file instead of manually changing the fonts in the design.

Open the layout, press Ctrl + H (Find and Replace). Click on “Replace All”.

Uh yes baby.

Done.

That is really awesome. Another example. You have a textbox with some lovely “Code.GetData” code in it. But where the heck is the “Code.SetData” code? Someone decided to hide it because he likes to see the world burn. Gladly, with Visual Studio you can easily search for the string “SetData” and find out which control contains this code. Nice!

Name DropDownField

Naming controls properly is a good practice. If you have a control that shows the CustomerNo, name the control CustomerNo. Easy. Do that with every control and you can use the name DropDownField or however it is called to find your control easily. This is only possible in Visual Studio Code, not in Report Builder.

Speed

If there is one thing that Report Builder does a lot better than Visual Studio, it is probably this one. When it comes to opening a layout with Visual Studio, this process takes a few seconds. Thus you try to keep Visual Studio open all the time so you do not have to wait everytime you reopen it.

Report Builder on the otherhand is lightning fast compared to Visual Studio. If you want to design simple reports, it might be a good idea to stick to Report Builder in order to profit from this.

Conclusion

Report Builder and Visual Studio have strengths and weeknesses. In this post, I explained 5 differences, but there are more. Knowing the differences in those tools helps you a lot in deciding which one to choose. There is no “better” tool in this sense. The tools fit different needs.

As a rule of thumb I would say:

Complex report with many controls and logic -> Use Visual Studio

Simple reports with few controls and logic -> Use Visual Studio or Report Builder

In the end everyone will have to decide for himself. If it is important for you that the tool opens right away, then Visual Studio is maybe not the best choice for you. If you like to create “clean” designs, then it is.

What are your experiences? Which tool do you prefer? Let us know! 🙂