September 6, 2011 at 2:18 am
peterw 85974 (9/6/2011)
Admittedly the SQL Server team is a rather closed and uncommunicative shop. I can't get so much as a "thankyou for your bug report, it has been queued for evaluation" out of them, in stark contrast to the Silverlight team which is extremely responsive provided you furnish a repro and a write-up and you don't waste their time.
Second this. I've been at the SQL team since the first release of SSRS to fix a bug in the CSV Renderer. In the end I wrote my own CSV Renderer so the problem is "solved" at least for us.
September 6, 2011 at 2:24 am
mm it's happening on 2 machines.
If I concentrated on it, I'd probably be able to create a scenario in which it happens 100% of the time.
I'm guessing it is a combination of factors leading to the result, however.
Hopefully some new hardware arriving in a week or so will make the issue disappear.
September 6, 2011 at 2:41 am
I disagree with most of this article - Microsoft have merged the table/matrix control and created the tablix. Whilst the learning curve for this is a little different from plain old table/matrix, there is much more control over the layout and rendering
The group pane is what you need to fix column headers or repeat them on each page (you need to open advanced mode and freeze the static groups representing those header rows), so there is a good reason for this view (which addresses points 2/3/4)
Shared datasets are not bad, if you have data which needs to be consistent across a set of reports, use them. You can change them:
http://msdn.microsoft.com/en-us/library/ee636147.aspx
Report parts are available in report designer - they are called subreports!
I agree with some of the other points though...
My single biggest annoyance is the rendering engines inadequate page handling - if you specify a header to be repeated on a page, it will repeat as long as there are new data rows on the page. If you perchance happen to have a very large single data item which wraps multiple pages, the rendering engine decides that it won't render the headers on any subsequent pages until its finished rendering the large data item.
One of our clients has a report which outputs some text which they have entered into an application. They can enter as much text as they like, and often this leads to large report items, which in turn leads to the issue above.
Noone's found a good solution for it - it should just work!
September 6, 2011 at 2:57 am
Have you noticed that if you go through that process of using the 'static' groups to set the repeating headers, then make some changes to the report (add field etc), the 'static' groups are no longer shown in the groups boxes but the header still repeats?
It could be 'by design' as the 'advanced mode' is also deselected..... although I would have thought it should remember that it has values set in advanced mode and tick the box/show the static groups...
September 6, 2011 at 3:18 am
For me it's the lack of being able to dynamically name a report, using an expression or similar, when creating a scheduled delivery. I'm still an advocate of the product in our business though.
September 6, 2011 at 3:34 am
My Favourite bad thing about SSRS
is exporting reports to excel, when the rows resize so you lose half your cell
2. another pet hate is having to use CTRL+C , I love CTRL+Ins (in the expression editor will ignore you if your pressing CTRL+Ins to copy)
3. gradient backgrounds are only available for a chart, I have to make my gradients into an image and store these for use in Tablix
4. not being able to select END of MONTH in setting up a schedule
5. Sometimes (possibly all the time, I've only just noticed) clicking on a dataset and clicking the query button , gives you a different query to that you might have saved when you changed the query via Dataset properties and click on the expression button for the Query
6. you must be convert everything in order to make comparrisons cdbl cint.....
7. lack of Render with last data button
8. A way for SSRS to remember the parameters you used last in report designer
September 6, 2011 at 4:36 am
Hi Andy. Shared datasets are a good thing if you consider that you can use SSRS not only for sql reports but also for mdx ones like me where you can not create mdx views for example as opposed to sql views.
Nice article anyway.
Nikos
September 6, 2011 at 4:52 am
I'll tell you what is REALLY missing, after working with Crystal Reports for years. Why can you not programatically set an object's size? Or a tablix column's size? Or an image's size? You can't. And it leads to so many hoops that you have to jump through to format things on the page. If I want variable column widths based on a database field or a user parameter, I have to make a copy of each set of columns (1 column, 2 columns, 3 columns, etc.) and conditionally turn them on or off. Otherwise you'll get stuff running off the page on the right. The only thing I've been able to programatically size are Graphs objects, and I believe that's because Graphs are really separate objects via Microsoft Graph.
September 6, 2011 at 5:11 am
I love it, and agree with the article whole-heartedly! Nothing is more confusing to me than trying to produce a Table report in SSRS 2008 or above. Tablix was the worst idea I have ever seen! Or at least the implementation of the idea was the worst, because I don't know what Microsoft envisioned from this mess. Did they bother to talk to people who write reports for a living, or was this just the idea some software designer dreamed up on his own?
I write reports for customers who want very specific page layouts, and who don't like to compromise. Tablix makes most of their requests either impossible or very very difficult.
Give me back the old Tables! Keep the Tablix if you like as a separate object, but don't force us to use it.
September 6, 2011 at 5:55 am
Great article.
Did anyone else miss snap-to-grid when they took it away?
I have to say, the shared datasets for consistency when using parameters sounds like a great idea.
How about being able to insert more than one column at a time?
I still get annoyed that the renderer for preview in Visual Studio is so different from that in IE. You create a report that you're really happy with in VS then deploy it and it looks yuckily different. And takes waaay longer to render (I'm not talking about data retrieval time, I'm talking about rendering).
The atom rendering extension (data feeds) is fantastic, but is there a way to use it in Excel without PowerPivot?
...One of the symptoms of an approaching nervous breakdown is the belief that ones work is terribly important.... Bertrand Russell
September 6, 2011 at 6:16 am
2 Great Articles.. Nice one Andy.
And I have to agree with earlier comment, exporting to .xlsx is much needed.:cool:
September 6, 2011 at 6:17 am
Color rendering is a peeve of mine. It's annoying to spend a lot of time setting up shades from the same color family for a chart, and then when the report is deployed, they all deploy as something like Light Blue.
September 6, 2011 at 6:36 am
Great post Andy. Really hit home with the confusion of the tablix and row/column groups. I would assume alot of developers would have been better off not knowing Reporting Services at all before learning 2008 rather than coming from 05.
September 6, 2011 at 6:50 am
Major Bad Thing: Give Me Back My Grid!!
In every other report designer I've ever worked with, including RS 2005, you had an option to use a snap-to-grid. Now 2008 will tell you this is still available, but it never shows up, even if you tell VS to display a grid.
See this MSC on Reporting Visual Studio: ShowGrid is not working and vote to have VS work the way it's supposed to.
I do like the new snap lines, but they are sometimes fussy getting down from 1pt to 0pt separation, with the moved element bouncing around and not droppable where I want. A grid would settle it in its proper location, no questions. This is HUGE for exporting to Excel without having the dreaded merged cell issue (which is another beef I have).
Great pair of articles, thanks!
Rich
September 6, 2011 at 6:52 am
I agree with two others already posted:
- Dynamically name reports
The other poster wanted to do it for scheduled reports, but we have a different problem.
A user wants to use Excel for some data analysis. He/she wants to compare or merge data from the same report with different parameters. The user runs a report (Report.rdl) and exports it to Excel, which starts Excel and loads the report (Report.xls). Then the user clicks back into the report and changes some parameters, clicks View Report, then exports the report to Excel again. BAM! Error! It tries to export to Report.xls again, and Excel complains about having two files open with the same name. (In some cases, Excel 2010 actually hangs and has to be killed with Task Manager.)
If SSRS could either (1) allow us to vary the name at runtime or (2) automatically add a unique value (timestamp?) to the end of the name for each run, this would avoid conflicts.
- Render to xlsx
Come on, how long as the xlsx file been the Excel standard? Since 2007?
Another thing we HATE about the Excel renderer is the dreaded merged cells...
Our users LOVE to export reports to Excel. However, it takes much too much time for our designers to manipulate headings and the tablix so things line up just right to avoid merged cells, which prevent users from easily manipulating the data in Excel.
It seems like the SSRS team has made great efforts to make the exported report render EXACTLY the same in Excel as in HTML/PDF/etc. While those efforts are noble, they are not all that necessary - people aren't exporting the report to Excel so they can print it - they are doing so generally for data analysis and manipulation - they don't care if the headings aren't exactly the same as the printed report.
My recommendation would be to add a report property that turns of "exact" rendering in Excel and avoids all merged cells. However it comes out, it comes out. We'll deal with the formatting.
(There is a "workaround" in SSRS, which is not really acceptable - there is a setting that turns off exporting of headers to Excel altogether and puts them in a comment field in the spreadsheet, across all reports. That's silly.)
Viewing 15 posts - 16 through 30 (of 78 total)
You must be logged in to reply to this topic. Login to reply