The pros and cons of Report Builder 3.0 over Report Builder 1.0

March 17, 2011

So yes, I’m still thinking about RB 1.0 vs. RB 3.0. We’ve made the move a few months ago from SQL Server 2005 to SQL Server 2008 R2. Most of our projects in the team, if they’re not cubes, are Report Builder 1.0 models.  I was really looking forward to seeing how we can move our users from Report Builder 1.0 to Report Builder 3.0. My conclusion? Except for a few very specific cases – we can’t.
We actually still have Report Builder 1.0 as a click once application from our Report Portal of 2008 R2 and not Report Builder 3.0. For the few Report Builder 3.0 customers we do have, we had a local install of the application.


Now I know, Report Builder 3.0 isn’t meant to “match” Report Builder 1.0 in its use. Report Builder 1.0 gives your user a semantic layer for him to create ad hoc reports against. In Report Builder 3.0 the main thought is that your power user will write a T-SQL query to pull all the data he needs for an ad – hoc report. In effect, that why Project Crescent was started – so you could get an answer to Report Builder 1.0 which hasn’t really changed since it was first released. So the comparison may not be very correct, but still…


I’ll go over what I think are the main points of what I liked (and liked less) in each version:




  1. Automatic fields – now I know that Report Builder 3.0 is all about you writing the query yourself, but creating a field for year and month for every date I pick is such a drag!! Getting them out of the box in Report builder 1.0 is that much more comfortable. The automatic sum and average you get for measures in RB 1.0 isn’t missed though. You get it already when you use the measure inside a table in RB 3.0.


  2. Filtering – even if I created the query for my user, I still don’t feel like he can use it all on his own. Specifically, unless I pre-define him parameters, he cannot filter easily and effectively by himself. Filtering the tablix in Report Builder 3.0 is equivalent to the filter on a table in Reporting Services. You have to either give an exact value which you know exists or know how to define an expression. The filters are defined with an “and” connecting them. Both of these points are in contrast to what Report Builder 1.0 gives you – a dropdown list of all the possible values for an attribute and a chance to connect the filters on the attributes with “or” and “any”.


  3. Visualization – obviously, Report Builder 3.0 demolishes Report Builder 1.0 visually speaking. The chance to use graphs and gauges from Dundas and maps really helps you get the point quickly and effectively to your user. I cannot put into words the importance of visualization (pun intended :) )


  4. Shared Datasets – Report Builder 3.0 gives you the chance to use shared datasets. That proved itself quite useful when I found myself creating quite a few different report that all used a parameter based on time. Instead of having to write the same dataset for the time parameter in each different report, I could re-use the dataset I created the first time, as I defined it to be shared.


  5. Bundling – in Report Builder 1.0 you have entities and attributes are of a certain entity. I think that really helps the user find the relevant fields. If he wants to get an attribute of a Worker, he would go to that entity and pick from it. Also, you have the chance to group a few entities together inside a folder or group attributes inside an entity into a folder. You can create perspectives on your model (like on a cube) so that your user can see only the entities that are in a certain subject, and not see the entire list of entities that exist in the main model.
    In Report Builder 3.0 however, you only see a long list of attributes. You can choose the order of the fields in the list and so it can be either alphabetical or all the attributes from a certain subject, and then from another subject. But it’s not terribly useful. Report Builder 3.0 is just for those specific fields, else the user gets lost. Report Builder 1.0 however, is for an entire world of content, and it’s still comprehensible and useful.


  6. Team System (or Source Safe if you will) – the thing that’s most important for me was saved for last. Report Builder 1.0 Project can be added to Team System (or Source Safe). That enables me to keep track of versions, give them labels, go back to the version from a previous date and so on. Problem is – Report Builder 3.0 doesn’t have that. That basically means that if I created a query for my user, and he somehow ended up deleting fields from it, then I would have to write it all up again – very worrying!

So, like I said before, we’re not moving away from Report Builder 1.0 just yet, even though it does have it setbacks. Here’s me crossing fingers for Project Crescent!

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

9 comments

  1. IndrajithMay 1, 2012 ב 17:45

    Hi,

    My report server is an external server and am trying to access the shared datasources within the report uilder.

    When i go to my report server url -> Datasources i see all my existing datasources.However when i try to create a blank report by chosing the existing shared datasources it looks empty.

    Please help me on this issue.

    Reply
  2. Ella MaschiachMay 16, 2012 ב 18:14

    I’m sorry Indrajith, but I don’t see why the report builder doesn’t recognize your data source on the shared data sources folder. Does it recognize other data sources in that folder?

    All the best,
    Ella

    Reply
  3. JerryJune 1, 2012 ב 17:04

    I believe RB3 can still bind to a dataset from a model which would hide the SQL from the user. But your other points are valid. Indeed, having worked with RB3 for about 3 days, it appears almost unusable for a typical RB1/2 user. For example, in the previous version, parameters could be added from a single window with no equation logic. In RB3, adding a parameter is at least two steps and requires the user to click the Fx button (very intimidating).

    MS has gone in the wrong direction with this product. RB was supposed to be a “power user” tool. Instead it is becoming a development tool like RD.

    Reply
  4. Ella MaschiachJune 2, 2012 ב 18:26

    Very good points you raised Jerry. Thank you for sharing!

    Reply
  5. mike berryAugust 30, 2012 ב 15:12

    This is very helpful. Thank you for making this post. I have a user that refuses to upgrade and we are upgrading their data source to 2008 and assumed, incorrectly that they would have no choice but to upgrade. thanks for the very informative posts!

    Reply
  6. Michael BerryAugust 30, 2012 ב 17:36

    quick question… I would like to know what to expect if I upgrade the data source for the report model.  will I have to upgrade the report model?  The report model and reports are currently on a sharepoint 2010 running integrated mode.

    Reply
  7. Ella MaschiachSeptember 2, 2012 ב 15:58

    Hi Michael,

    I can’t say that I’ve used Report Builder integrated with SharePoint, but I have updated an entire RB 1.0 project (data source and model) and it hasn’t changed a thing in the reports. So you can update both without a worry I believe.

    Reply
  8. Ella MaschiachDecember 19, 2012 ב 8:57

    Hi Bini,

    Using a query like:
    select reportid, Path, Name, Parameter
    FROM [ReportServer].[dbo].[ExecutionLogStorage] e
    inner join [ReportServer].[dbo].Catalog c
    on e.reportid = c.itemid

    You can see which user ran the report and with what values for each parameter. This is also true for RB and not just RS reports. This is also provided that you run the reports with your users credentials and not through a general user for an application.

    All the best,
    Ella

    Reply