March 26, 2012 at 9:39 pm
Comments posted to this topic are about the item Report Builder or Reporting Services?
Andy is a director of Wise Owl[/url], a UK company providing training courses (and occasional consultancy) in SQL, Reporting Services, Integration Services and Analysis Services, as well as in many other Microsoft software applications. You can see more about Wise Owl's SQL Server training courses here[/url].
March 26, 2012 at 11:04 pm
Hi Andy
Not a bad summarisation of the differences between the two apps. I think most developers would have to opt for Reporting Services but in our business, end users (interested in reporting) outnumber developers by 20:1. Only one of them is up to speed with Visual Studio and she came from a developer background. My vote is for Report Builder for the vast majority of the business... and to get them off my back creating routine reports 😉
Allan Gartland
March 27, 2012 at 12:17 am
We prefer SSRS, because we use some versioning system.
When someone changes an existing report with Report Builder, you aren't able to retrieve the previous version (unless they will save their changes to a new report).
When we make changes through SSRS, thanks to our versioning system, we can always go back to the previous version if we want.
I think this is an important difference for a lot of people, certainly for us 🙂 !
March 27, 2012 at 12:17 am
Thanks this is a useful differentiation and would have helped me a few years back 🙂
I'm sure you know these things but it might help someone new reading this:
The visual studio environment is introduced as BIDS, and then refered to as SSRS in the rest of the article. The term SSRS really encompasses the whole product including the Reporting Services instance you would install as part of SQL Server, the Report Manager website, the ReportServer and ReportServerTemp databases.
When you install BIDS as an extra from the SQL Server installation disk, you don't get the standard Visual Studio .NET language projects. This is important because BIDS doesn't require separate licensing. You've already paid for the SQL Server licenses so the BIDS tool is a free extra with no installation limitations, likewise the Report Builder tool that you download from the report manager website.
If you install Visual Studio from Visual Studio disks, you don't get the Business Intelligence templates and need to install BIDS from the SQL Server disk. Various versions of Visual Studio will happily co-exist on the same machine.
March 27, 2012 at 1:09 am
A quick reply on your "Strange Bugs"
"2. When assigning a parameter for a subreport, SSRS has no dropdown - you have to type the parameter in. When you consider that the parameter name is case-sensitive, this increases the scope for error for no obvious reason."
My experiences have shown that you can get the subreport parameters as a dropdown, but you have only have 1 chance to do so... and that is when you 1st assign the add the subreport:
1 - add a subreport item to your report.
2 - in the item properties assign a subreport (from your dropdown box).
3 - immediately add the 1st parameter which should give you a dropdown list of the subreport parameters to chose from.
4 - go through and add all the subreport parameters and using the dropdown before exiting out of the properties.
* once you exit out of the subreport item properties and re-enter you can no longer add and use the dropdown option.
March 27, 2012 at 1:10 am
Great article, bar the proof-reading of the spelling mistakes 🙂
March 27, 2012 at 1:11 am
Another thing missing from Report Builder is the ability to work on several reports at the same time as a project (as opposed to individual reports) and the ability to use source control.
March 27, 2012 at 1:43 am
When you use SSRS (the product not BIDS bad naming in the article) in a web app that you sell as a product then it has to be Report Builder since you can't distribute BIDS nor is it a click once install.
March 27, 2012 at 2:02 am
My experience is that ReportBuilder is already too complex for the majority of end-users. You really need people who can understand data, relationships and can write a (basic) query (SQL, not MDX because this is certainly not for end-users). An analyst with some technical knowledge (often also the company's excel guru) could work with the tool but usually there are not many around. I think they are also the only people who can qualify for any 'self service bi' tool to be honest.
March 27, 2012 at 2:05 am
Good article. I have two opinions to share though:
1. I do not like that the development environment within BIDS was referred to as SSRS. Reporting Services is the whole package or module of MS SQL Server. The interface in BIDS should better be referred to as the Report Designer.
2. Microsoft did intend the Report Builder towards more business users rather than technical people. However, based on my experience, they did not accomplish it very well. Report Builder is only very easy if you want to simply and directly use fields from a database to build a very simple report. However, business needs often extend beyond that, and soon complications quickly arise with the need for special sorting, groupings (anyone experienced trying to sort a report with multiple groups?), calculated fields, parameters, linked reports and expressions.
We attempted to migrate from excel reporting to Reporting Services, and only a handful of technically-minded people managed to catch on with Report Builder 3.0.
The interface is also a little weird, and requires time and constant use in order to get used to it without forgetting - something which business users cannot afford much.
As a report developer however, I am quite happy with being able to develop professional-looking reports with Reporting Services.
With regards,
Andrew.
March 27, 2012 at 7:19 am
I echo the earlier comment that you maybe shouldn't use "Reporting Services" as a name for the BIDS client tool. Good article, especially for beginners, but that may further confuse people.
March 27, 2012 at 7:37 am
I think the reason MS "decided" to go one way with Report Builder and another with BIDS is really where they both came from. Report Builder came from a long line of end user tools most popular in Excel (MS Query) and many of the behaviours are still the same. BIDS on the other hand came from the development side.
Yes, one is targeted towards the BI end user and the other towards the developer, the most likely reason they are so different (really the reason many of the useful features are missing from Report Builder) is that there are different units within MS building them.
March 27, 2012 at 7:37 am
The problem with the approach Microsoft took in creating these 2 tools is that they created virtually the same tool for two very different audiences. Since the release of Report Builder 1.0 the tool has only gotten more difficult for end users to develop reports instead of easier. Besides, if an end user wants a more complicated report (that requires expressions, etc.) they should pass it on to true developers. Too much power in untrained hands can be a bad thing.
March 27, 2012 at 7:39 am
We're using SSRS BIDS 2005, and it seems that SSRS 2008 has a better developer interface.
That aside, I can't see my user community having success with Report Builder. Given the bevy of end-user visualization products on the market (Tableau comes to mind), I think Microsoft has a lot of work to do to compete in this space.
___________________________________
Brian A. Zive
Assistant Director, Systems
Business Intelligence Analyst
Massachusetts General Hospital
Development Office
March 27, 2012 at 7:41 am
I use ssrs for reports that are consumed by web pages.
The bulk of my users use access (ugh) to create their own stuff. As a replacement, I'll be nudging them to use excel's powerpivot very soon. My goal with powerpivot is basically the same as a dev's goal with reportbuilder: to get the bigwigs upstairs off my back, and make their own $#%#$ reports. 🙂
Viewing 15 posts - 1 through 15 (of 38 total)
You must be logged in to reply to this topic. Login to reply