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:
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.
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”.
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 🙂 )
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.
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.
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!