March 27, 2012 at 8:43 am
I much appreciate the effort going into this article. The most important "take away" for me is the strong similarities between SSRS in R2 and the current Report Builder. I used to periodically check out Report Builder but stopped a few years ago but I don't think I'll need to for awhile thanks to this article.
Couple of other comments:
I didn't understand "Report Builder... is always free, whereas unless you get Visual Studio Express SSRS is anything but." Doesn't Report Builder come with SSRS and doesn't SSRS come bundled with SQL Server? If you own SQL Server you own SSRS. There is no extra cost.
I have NEVER seen a GUI query designer that was good for developing queries with ANY level of complexity. They are at best handcuffs and much like wizards in that they prevent any true learning from taking place. You are better off coding in the SSMS text editor and pasting into your dataset or calling a stored procedure from it.
March 27, 2012 at 9:14 am
One of the great things about contributing articles to SQLServerCentral is the quality of the comments. Thanks to everyone who has commented so far - all good stuff. Apologies for referring to the product as SSRS and not BIDS; I take the point. Fascinating snippets about getting subreport parameters to appear too!
Everything I've read confirms what I feared was my prejudice, but now think is just rational common sense: Report Builder doesn't make much sense. I taught a Report Builder course last week, and by the second day we'd switched to BIDS. Reasons included:
- the expression builder is much better
- you can work on lots of reports at the same time
- the query builder is much better (particularly for drawing ad hoc relationships)
- you can work on reports until they look right, then deploy them to the live server
The point about source control being available in BIDS is also a good one.
Andy
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 27, 2012 at 9:19 am
jshahan (3/27/2012) You are better off coding in the SSMS text editor and pasting into your dataset or calling a stored procedure from it.
Oh. I didn't realize people did anything ELSE. lols
March 27, 2012 at 2:11 pm
"I have NEVER seen a GUI query designer that was good for developing queries with ANY level of complexity. They are at best handcuffs and much like wizards in that they prevent any true learning from taking place. You are better off coding in the SSMS text editor and pasting into your dataset or calling a stored procedure from it."
Totally agree.
I see staff writing several gui reports and then combining them in excel, so defeating the purpose of a report writer. Better to teach a few users SQL.
March 27, 2012 at 4:10 pm
busasquatch (3/27/2012)
We're using SSRS BIDS 2005, and it seems that SSRS 2008 has a better developer interface....
In terms of SSRS 2005 BIDS v SSRS 2008 R2 BIDS, myself and my co-developer have found that even though 2008 R2 offers more features, control and flexability... in general it is more tedious to work in and it increases report development time.
Can't comment too heavily on ReportBuilder because we rarely develop in it.
March 27, 2012 at 4:59 pm
A couple of my "BIDS vs. Report Builder 3.0" thoughts:
Report Builder 3.0 coupled with some well designed Analysis Services cubes and/or Report Models provides a good, intuitive report design experience for end-users.
I find the inability to use Report Parts in BIDS quite annoying. You can create/define Report Parts in BIDS, but only Report Builder actually lets you use them! Report Parts also seem to be treated as 2nd-class citizens in BIDS - i.e. there are no "Report Parts" objects in a BIDS project.
Installation/Deployment of Report Builder 3.0 vs. BIDS is also worth highlighting as a significant difference.
Integrated Version control in BIDS is also a significant difference - Report Builder does not provide this capability directly, although if SSRS is running in SharePoint integrated mode a similar capability can be achieved via Version History on the SharePoint Document Library...
Piquet
March 27, 2012 at 11:57 pm
busasquatch (3/27/2012)
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.
They make a good shot with PowerPivot and PowerView in SQL Server 2012.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
March 28, 2012 at 12:02 am
Report Builder is for report developers who for some reason don't have Visual Studio installed. And IT lost the DVD of SQL Server...
Personally, I haven't seen an end user use Report Builder 3.0. I did once with Report Builder 2.0, using the Report Models, because using a metadata framework (such as the Universe in BO or the Framework in Cognos) reduces complexity enormously. It's a bit of a shame MS ditched the Report Model instead of working it out a bit better. As longs as end users have to write their own queries, the tool will not be widely used. And if the end users have to wait for IT to write them a stored procedure or view, what's the point in making your own reports?
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
March 28, 2012 at 8:14 am
Obviously, BIDS is a better tool for IT. As an IT analyst, I use both. It would have been a better article if you had highlighted some of the benefits of Report Builder for the business user. Report Builder allows business analysts to publish to the same collaborative environment as the developers using BIDS -- there is no need to develop one-offs using another tool like Access, which is typically what we did prior to Report Builder 3.0. So it is very good as a collaboration tool allowing IT and business to work together with the same end result. Plus, you can't beat RB for making quick formatting changes (just open report builder, make the change, and save...) -- no need to download the .rdl. That saves me a lot of time as a report developer.
March 29, 2012 at 1:51 am
Extra Point on strange bugs 2
If when you edit the parameters a second time, you click on the report selector drop down but don't change the report, the parameter name drop downs work again.
March 29, 2012 at 9:45 pm
Jim Johannsen (3/27/2012)
"I have NEVER seen a GUI query designer that was good for developing queries with ANY level of complexity. They are at best handcuffs and much like wizards in that they prevent any true learning from taking place. You are better off coding in the SSMS text editor and pasting into your dataset or calling a stored procedure from it."Totally agree.
I see staff writing several gui reports and then combining them in excel, so defeating the purpose of a report writer. Better to teach a few users SQL.
Agree on the query part...
For us both of these tools is simply a waste of time. We have reports for either generating Excel sheets or official reports as PDF. The tools are neither simple or complex enough to fit our needs. We focus mostly on providing queries and an easy, online, "non-studio" way to publish it. It's been great to be free from studio dependency and the only thing required to upgrade so far is to rebuild for a new .Net framework from time to time...
March 30, 2012 at 2:01 pm
Another benefit to Intellisense...saves time! A lot of time.
Good article for the novice.
April 2, 2012 at 3:30 am
We are trying to roll out Report Builder to just one 'expert user' and it is taking such a lot of effort to make it work for them that one wonders whether this is actually cost effective. I think the end result will be that the user will hardly create any reports, but rather create lists to export to good old Excel to manipulate.
The only reason we tried to roll it out to this user is that they had too many slightly different report requirements to make it worth our while to recreate in reporting services.
April 2, 2012 at 6:32 am
tim.kay (4/2/2012)
We are trying to roll out Report Builder to just one 'expert user' and it is taking such a lot of effort to make it work for them that one wonders whether this is actually cost effective. I think the end result will be that the user will hardly create any reports, but rather create lists to export to good old Excel to manipulate.The only reason we tried to roll it out to this user is that they had too many slightly different report requirements to make it worth our while to recreate in reporting services.
In this situation, cubes can be very handy too!
Since recently, we have some cubes now in our company, and I must admit, the speed at which we can deliver answers to questions which change always a little part, is superb!
May 30, 2014 at 1:57 am
The query designer in reportbuilder has some great restrictions:
no ability to use parentheses graphically (when you want to use "or" instead of "and"), unless you correct it in sql-text.
no ability to duplicate a table graphically (parent/child) tables
Viewing 15 posts - 16 through 30 (of 38 total)
You must be logged in to reply to this topic. Login to reply