Opinion on RDLC v/s RDL

ssingla

RDLC : New reporting layout for use in NAV 2009 RTC
RDL : SQL Server Reporting Services

Before today, I never saw how RDLC reports are prepared and executed in RTC. I attended a training session by Microsoft on NAV 2009 SP1 today and found RDLC as annoying. Neither the stored procedures were available nor any SQL Query. To compound the problem each and every change in NAV Classic report will mean complete working on the RDLC format. Further we cannot add fields in the RDLC format.

I am a big fan of SQL reporting services (though I met MVP:SQL last month who said reporting services needs a lot of Improvement) and have found RDLC as stupid.

Though RDLC is a big improvement over classic reports but at the same time it has increased the effort for preparing a report and is quite cumbersome to prepare.

Would like to hear comments from persons who are using RDLC & RDL.

generic

I suggest to direct your complaints to MS.
Here they are viewed as Troll.

Good luck.

ssingla

generic wrote:

I suggest to direct your complaints to MS.
Here they are viewed as Troll.

Good luck.

I wonder that be true. I have seen lots of negative comments about the product but this has not happened.

generic

Just wait and see how many useful comments you'll get.

Consider mine as troll.

DenSter

ssingla wrote:

Would like to hear comments from persons who are using RDLC & RDL.

I have not had a chance to really dig in, but on first glance I agree it's definately not as easy as we're used to. I worked on the DEV II material for NAV2009 and wanted to put together a really useful chapter for this (and build a document report with pageloop and copyloop), but it was not in the budget, and all we had time for is the lame colored lines. I tried to figure out how the standard invoice report works and wanted to blog about that, and just could not figure it out. I asked the NAV team a number of times for help but my emails seem to have fallen into a black hole, and I have not yet received any replies. They did come out with the new training material, and there's a training session alter this month about it that I intend to take.

The most annoying part (I don't know how anyone thought it would be useful that way) is that in order to be able to use a field in the RDLC, you seem to have to put the field as a control into a section in the NAV report object. The other way around, if you remove a textbox from a section, the dataset in the RDLC is no longer valid, and you get error messages that don't really tell you what's wrong. We should just have access to all fields in the tables that are defined in the report's dataitems, although I am sure there is a very good reason that we don't.

The new reporting training material is on my computer, and I intend to take the training later this month. Because I simply don't understand how it works yet, I wouldn't say "stupid" just yet (although I am REALLY annoyed by it). I'll get back to you after I take the class though

kine

I think that biggest problem is in the way, how the dataset for the RDLC is created. First the classic client is started to do all the business logic, than all data which are on the classic sections are flatten into one big table and this is source for the RDLC. If you want to have access to all fields from used tables, it will mean that this flat table will grow and grow. Even without this it is very big in more complex reports. But without this process, you will not have the business logic of the original report behind it. It means it is compromise between "running report business process" and "access to the data of database".

RDL will mean to have access to all data, but without business logic in NAV which is processing and preparing the data...

David_Singleton

DenSter wrote:

We should just have access to all fields in the tables that are defined in the report's dataitems, although I am sure there is a very good reason that we don't.

There is a very good reason for it, I was at a session in Denmark some time ago where this was explained (you were sitting next to me actually ).

Basically think of it as though the normal Navision report is scanning all the required tables and generating a mini cube. This cube is presented as an XML file to SSRS so that a report can be built from it. Lets say in the report you have 10 tables (easy in a sales invoice counting the globals) then EVERY field in every table in every record would need to be packaged into the xml, making it huge. The use of controls means that we can decide what data is used and what not.

Its not ideal in some cases, but its a good compromise for performance.

David_Singleton

Sorry just read Kamil's post, basically we are saying the same thing. Sorry for the duplication.

As to the original question. My personal believe is that there is room for both. Most of the compromises came down to three things. 1/ Performance 2/ Easy of use, especially giving the user a good feeling of integration, that they launch reports direct in Navision 3/ reaching a compromise between the complex data model that we are used to in Navision and the simple cube/flat file that a typical SSRS developer is expecting.

I would say that any Navision developer or any SSRS developer is going to see the holes missing, because they don't see the other developers point of view. They will always expect it to work like they are used to. But from a client point of view it means they get the simplest integration. But at a cost of more expensive report development. But Navision reports are so cheap to develop now anyway, that a little extra cost for the massive improvement in report quality is (IMO) justified.

And also what the end user sees now is that they can modify report layouts, without the risk of damaging the reports business logic that they can do in Navision.

Ok so that's the logical aspect. How about my gut feeling.

I really don't like the new tool. I think that more work should have been made to create a fully integrated SSRS solution. I am in the middle of a big 2009 implementation (just been waiting for SP1) and we plan to use the Navision reporting solution for all your typical documents like invoices and orders that need complex Navision logic. But all reports like accounts and Item lists and sales report etc we will do in SSRS. It is a compromise and we need to understand that. I am sure that 2011 will have full SSRS integration.

So basically I see that for now companies will be using both. We want the ability to automate a lot of reports. And even documents ultimately we want the SSRS ability to schedule and convert pdf and email etc.

DenSter

I agree with you David that it will always be a compromise, and as the app matures it will become more user friendly. What would be a big step forward is to be able to include SSRS reports in the RTC, at least be able to launch them within the context of the user's current task. With the new ability to create new UI elements I am sure that there will be people who will come up with creative solutions for that as well.

One thing's for sure though... development for reporting is NOT quick and easy anymore

ssingla

kine wrote:

I think that biggest problem is in the way, how the dataset for the RDLC is created. First the classic client is started to do all the business logic, than all data which are on the classic sections are flatten into one big table and this is source for the RDLC. If you want to have access to all fields from used tables, it will mean that this flat table will grow and grow. Even without this it is very big in more complex reports. But without this process, you will not have the business logic of the original report behind it. It means it is compromise between "running report business process" and "access to the data of database".

RDL will mean to have access to all data, but without business logic in NAV which is processing and preparing the data...

With RTC we have moved to 3 tier architect which means the processing should happen on the application layer and presentation layer should only display the results. Then why we need flat file? NAV can only generate the RDL format and the RDL can be executed on the server the way SSRS execute.

ssingla

I am also thinking that it could have been better if there would have been two objects a) Classic Report 2) RTC reports just like Forms and Pages. Both are independent and dependent to some extent.

davmac1

I think when NAV drops support for SQL 2005, they should convert the company name to a simple schema name instead of the current:
"Hellaciously long company name that some project manager thought was descriptive$Item".
The table would then be companyname.Item.
Then reports could be generated from tables qualified by the schema name and mybe simplify the whole SSRS process as well as making it easier to generate reports outside of NAV for multi-company sites.