September 6, 2011 at 10:25 am
Singanan Krishnasamy (9/6/2011)
There are few more I identified, if someone can verify these issues are correct would be great.1. Drill down, the + and - symbol conflicts when the visibility of an object ( table or any group level) is configured to hide and assign an toggle item to it... the behaviour of the + and - symbols works as oppose to they are supposed to be.
you need to write an expression against the InitialToggleState property of the text box as well as the grouping
Shame its not intuitive to realise that you've grouped and rolled up one category but left the other expanded
September 6, 2011 at 10:30 am
Can I stress that I wrote TWO articles! The other one listed the 10 good things about SSRS. My personal opinion is that Reporting Services is a superb product, and I take my hat off to Microsoft for producing it, but that doesn't mean that I can't highlight the odd niggle.
On specific issues:
- not being able to use CTRL + INS to copy in the expression builder would be number 11, I agree (it's only a tiny thing, but it drives me nuts!)
- not being able to output to XLSX format: fair enough
- I've clearly misrepresented shared datasets, so apologies for getting this wrong
- I never used the grid, so didn't notice it had disappeared (for me the blue alignment lines are so good that they make the grid redundant)
Thanks to everyone who has commented on the article so far.
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].
September 6, 2011 at 10:31 am
Nice to see good constructive criticism that points to the usability and functionality of the SSRS report set. I use the reporting side of SSRS very little but have worked on the backend with the SSRS Web Services and Data-driven report extensions. These are super and have advanced nicely over the 2008 and 2008 r2 releases.
Using the backend web services one can access a specific report and generate a single report and store it online for a snapshot archive in formatted form, or prep a version to email to a user without much work.
Developing a custom data-driven extension you can generate your report of choice and distribute it in any way you choose. This is a huge advantage.
Did they change these services significantly in r2? No and it was one of the best decisions they made.
Not all gray hairs are Dinosaurs!
September 6, 2011 at 11:32 am
One problem I have noticed is in regards to exporting a SSRS 2008 R2 report to Sharepoint 2010. If you are using shared data sets then you have to export each shared item as well as the actual rdl and then go back into the report on Sharepoint and reconfigure all the connections. At least this is what I have had to do. It is very frustrating. In 2005 I would have to reconnect data source connections after deploying but thankfully that was usually no more than 2 sources per report. For SSRS 2008 I have some reports with 3 or 4 shared data sets plus multiple data sources. For this reason alone, I am avoiding shared data sets as long as I am using Sharepoint as our reporting site.
For the other pain points, I agree that Tablix is confusing. It seemed like a great idea when I first heard about it because there were definite limitations with the matrix in 2005. In using it however, it has not been as straight forward as I expected. hopefully with more practice, that confusion will subside....
A point regarding maps, we have come across limitations when using the map objects where we have hit the limit on how many points a map can display. Using spatial data points we have thousands of data points by US postal code. In management studio, you can run a query by zipcode and see all the points in a US map-like shape in the spatial output window of a query. (We have enough data for each zipcode so that most of the country fills in.) However, in SSRS, if we use the US map by state and bring in the US state id and postal code plus whatever metric we are counting over (customers usually), then the report errors out saying we have exceeded the number of points that can be presented. This forces us to have to sum our data by state ID which limits the usability of the maps.
September 6, 2011 at 12:31 pm
I would say that the total redesign of the the rendering engine is the biggest issue for me.
I use SSRS primarily to design dashboards (i.e. report with 4 subreport panes) and drill-down reports. With the change to the AJAX rendering engine, the rendering is so slow that dashboards are no longer feasible. This is unfortunate as the greatest improvements to R2 were in the form of dashboard items: indicatators, gauges, sparklines, etc.
The rest of these items here are valid, SSRS to me has always been built for flexibility over usability, and that's a trade-off I'm willing to make every time. Most of these items seem to fall into that category. The rendering engine however is a deal killer, and a step backward in one of the hottest areas (data visualization or whatever broad term is currently in vogue). I've moved all my dashboard development to PerformancePoint, but that isn't a viable option for clients that don't have enterprise licenses for SharePoint. SSRS has moved from being a valid solution in this area to not, and that has had a severe negative impact for me.
September 6, 2011 at 3:47 pm
>>Noone's found a good solution for it - it should just work!
Um... I wouldn't say this is necessarily a *good* solution... but I think maybe I did find a solution for it. See http://spacefold.com/lisa/post/2007/09/22/MaxHeightAvailable-Rules.aspx where I more-or-less muse about the philosophical implications and then refer backward to the code for SSRS:
I know that the situation covered there is not quite the same but I think this way of thinking about your client's case will give you a way to handle it.
September 6, 2011 at 3:56 pm
The scheduled delivery capability is only a very small part of what one would want to do, sure. But it's a feature of Report Manager, not SSRS. Report Manager is just a default front-end. you can do *much* better than this, whether you want to re-do all of Report Manager or just the scheduled delivery capability, which is hardly more than stubbed in in Report Manager.
One problem is that the "scheduled delivery" interface is the simple "one size fits all" version, and almost everybody who needs more than this needs something less generic for the delivery dates. In my case, a typical requirement would be "one day before marks reporting opens", and this would obviously be driven by a more complex calendar query than the brain-dead report manager UI could allow.
But this is okay. Just don't confuse the Manager with Services and go ahead and write an SSIS job to do the scheduled delivery you really need.
>L<
September 6, 2011 at 3:57 pm
I agree on the shared datasets.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
September 6, 2011 at 4:02 pm
Are you trying to print it on the server or, using ReportViewer, on the client side in a web form?
There is a solution for this, I'm pretty sure, but I'm *not* sure exactly what "autoprint" means in your environment.
Whatever it is, I don't think it involves using the ActiveX control for printing or whatever-it-is that is attached to ReportViewer. is that what you are talking about?
>L<
September 6, 2011 at 4:06 pm
>> adding parameter through the UI missing
It is?
Not sure... you're talking about when using the Report Designer in Visual Studio, right?
1. View menu -> show the Report Data window
2. There's a little dropdown thingy that says "New", from which you can pick Parameter. The Add Parameter dialog appears when you do that. Good enough? (of course you can also rightclick the "Parameters" folder in the Report Data window, and pick "Add Parameter" from there.)
>L<
September 6, 2011 at 4:10 pm
While this is most excellently true, the real problem is that you have to allow for different renderers to have the ability to handle your color shades different ways.
This used to be why we had "web safe colors" even in HTML forms.
But in SSRS you have not, just alterations in monitors and graphics cards, but also alterations between what you'll get in MHTML, a PDF, and on your printer. Not to mention some other renderer which somebody might right.
In some ways this isn't a completely solveable problem, but I agree that picking from a chart (regardless of which palette type you pick, among the charts) makes it harder to manage. I end up creating a table of colors in my DB and referencing them as variables. It's like a variation of "web safe colors", only it's sort of "x-renderer application safe".
>L<
September 6, 2011 at 4:12 pm
>>And a renderer for XAML so reports can be rendered directly into the UI of a WPF/Silverlight application without a lardass third party report viewer control.
You sort of have one: XML renderer + XSLT.
>L<
September 6, 2011 at 4:20 pm
john.cullom-964907 (9/6/2011)
SSRS has moved from being a valid solution in this area to not, and that has had a severe negative impact for me.
We actually avoided SSRS in the past due to rendering issues (database hits) and focused on Performance Point just to find that PP lacked a lot of flexibility in regards to designing graphs, object types and customized labels. So we are actually looking at building a lot of our components in SSRS 2008 and throwing them into SharePoint. If the AJAX has somehow made rendering even slower than it was before then I may have to look for yet another tool. PowerPivot is the only other visualization option we have right now. Thankfully we are now hitting a cube instead of a relational DB so there is some performance gain there. Maybe we won't have to leave the MS stack.
September 6, 2011 at 4:25 pm
Andy, you made a lot of good points.
I'm personally annoyed that they didn't make it easier to write embedded code in a report (you can size the dialog window but you can't format easily when typing in that thing, and if anybody can tell me where I can set the font for it I'd be hugely grateful).
One thing I am scratching my head over, though: the Number format dialog disappearing. I haven't noticed this. What shows up instead, when this happens?
Could it be something about whether you have the textbox highlighted or a single placeholder highlighted at the time? Just wondering.
Another thing, now that I mention placeholders -- I don't think you mentioned them in your "10 Good Things" article, and they really are the bomb. I still can't get over how you can do the equivalent of Word Mail Merge with *no* effort now.
You mention in the "10 Bad Things" that you can't see the <<Expr>> -- actually you can, you can make the label of a placeholder read whatever you want it to read, including a partial expression with an ellipsis if you would like to do that. Typically, though, I put in an english language label that expresses what the expression does, rather than the partial expression itself. Especially if you're doing something like the aforementioned mailmerge, this makes for a readable report design surface.
Also - Report Builder 2.0 and 3.0 using the real RDL format (if memory serves, 1.0 did not) could be a big new plus.
Thanks again for writing both articles. >L<
September 6, 2011 at 5:41 pm
Lisa Slater Nicholls (9/6/2011)
One problem is that the "scheduled delivery" interface is the simple "one size fits all" version, and almost everybody who needs more than this needs something less generic for the delivery dates. In my case, a typical requirement would be "one day before marks reporting opens", and this would obviously be driven by a more complex calendar query than the brain-dead report manager UI could allow.
Delivery dates are just one problem with how SSRS handles scheduled reports.
Another problem is that it totally pollutes the SQL Server Agent Jobs with GUID-named jobs, making it very difficult to find and maintain legitimate jobs. From a DBA point of view this was extremely frustrating and left me with two choices:
1. Alter the msdb.dbo.sysjobs_view such that anything that was created by sa and has a name like a GUID was hidden from view, or renamed, or
2. Move SSRS to another SQL instance.
Being limited to one report attachment per e-mail is another. The ability to batch up a series of reports on a single e-mail would have been a very useful feature. We wrote our own report robot that does this, which also gave us a third option for the GUID-named jobs problem.
Viewing 15 posts - 46 through 60 (of 78 total)
You must be logged in to reply to this topic. Login to reply