Have used Sparkline in Matrix many times with no issue, now working for a new company and cannot get them to render correctly at all. They work great in VS. When deployed the matrix cell renders the row data for each column but within the cell it also renders the sparkline for all rows. so there are multiple sparklines in one cell each representing a different row, and this is repeated in each row of the report. using SQL 2008R2 VS2010, IE11. In chrome it does render only one sparkline per row but the formatting is OFF and I always make my users use IE in any case.
I have searched a lot for a solution and found nothing of help.
This is a really cool feature in SSRS and I am really keen to continue to use it as it provides a rich user experience for visualising raw numbers.
Any help would be awesome :)
Report viewed via IE11
Related
I have 8 subreports in one report and want to create the slideshow using the expression in 'visibility' property. I want refresh time of report 15 seconds and sequence should be same as in the report.
SSRS doesn't have built-in functionality for this. One option would be to set up a page that has the reports embedded in it. You could adjust the timing and visibility using JavaScript.
There's going to be a loading delay each time you switch reports. Make sure you also consider enabling caching on the reports to optimize the performance.
I've answered something very similar recently here Can you rotate through visible sub reports in report builder 3?
The sample project I supplied is no longer part of the question so I'll link it again here. The Sample report is for use in ReportBuilder 3.0 for sake of compatibility with the last OP's setup.
The sample loops thru 3 text boxes but the principle is the same as I described in the answer.
Hers the link to the sample..
https://1drv.ms/u/s!AvWOxxoIjY1UlwatsmA7u3vJjQBZ
We are currently integrating with SQL Server Reporting Services and have got most of the functionality we require in place now but I am stumped on how do get the last bit working. On the current manual system at the bottom of the Excel spreadsheet is a Word Cloud which we would like to emulate in SSRS. I have constructed a DataSet that returns a list of words and their scores but I cannot work out how to create a word cloud from it.
I have followed the example below and got it working successfully and it looks great in Visual Studio but when I look at it in Excel and as a PDF its just not very nice at all.
http://www.sqljason.com/2012/03/making-tag-cloud-with-ssrs-rich-text.html
The main problem is that the results are loaded into a table (that has to be shrunk so it is unobtrusive) the some VB generates the HTML that is then rendered in a Text Area.
When I look at it in Excel the table is clearly visible (its huge) and in PDF form it is missing.
Does anyone know of an extension or plugin that I could use to display the word cloud or a better way of doing it?
The alternative would be to embed it as an image and call a web-service that creates the word cloud on the fly but it does seem like a lot of work for something that is probably a fairly common requirement.
Thanks everyone in advance :)
You say it does not look nice and then that it is missing. Which one? Why are you having to use a Dataset for words generated? If they are just arbitrary words you could set them up in free floating text boxes. I am not getting why to generate text you need to apply a dataset to it unless there is an object like a 'list' you have rules that you HAVE TO use a dataset.
Without a picture (which you do not have enough points to show) it is hard to tell what the cross applicatin problem could be. You are using a blog as a basis which the person could be using 2008R2 or 2012 SSRS for as well which makes it hard to troubleshoot.
My guess is you are applying a boxing layer, positioning or overlay that the PDF renderer does not like. My suggestion would be to start a small report with just his example only and see if it works as is in 2008. He seems to have someone mention on an issue of positioning which is the biggest culprit of problems with SSRS and multi format saving. If you can get the CORE part of your report working as he described I would think you may be able to use that as a 'subreport' inside of another report if you want more than one object to a report.
My ASP.NET site uses Report Viewer 9.0 to run reports from a Reporting Services 2008 R2 server. For most reports, Report Viewer accurately shows the number of pages a report will print on (i.e. in its paging fields in the header). However, there is one report which always shows as using only 1 page, whereas it always prints as 2 pages.
(This might found like a trivial issue as there is no impact on actual printing, but its one of those things "the client finds confusing" so has to be investigated :) ).
Some details:
All the reports that show accurate page counts are fairly simple "record list" style reports - based on one/more tablixes, with texboxes for titles
The one report with a problem is a 2 page "customer invoice", constructed as follows:
The dataset is a single record containing details of an order (customer name, order date etc)
The report is built from 2 rectangles arranged vertically, with both being the exact width and height to fit on 1 A4 page (19cm x 27.7cm which allows for a 1cm margin on the report)
There are no "automatic page break" properties set on any controls (e.g. page break after rectangle #1). This hasn't been necessary as the sizing of the rectangles makes the report print perfectly on 2 pages.
(This is probably irrelevant) Each rectangle's visibility can be toggled by a boolean report parameter - "Print page #1" & "Print page #2". This also works fine for controlling which of the pages print.
I do not want to set the "automatic page break" on either rectangle as this would cause blank pages to print if the report parameters caused one or other rectangles to be hidden.
What else can I do to make Report Viewer realise there are 2 pages?
Edit: its not an issue with just Report Viewer - the SSRS Report Manager shows the report as 1 page, and so does Visual Studio Report Designer when previewing the report. Both however show 2 pages when doing a Print Preview.
In some cases this may be caused by the fact that the PageCountMode defaults to Estimate.
As far as I knew you can't do much about that in ReportViewer 9.0 connecting to a 2008 report server. The only solution I knew of is upgrading to 10.0. However, in this social.msdn thread they suggest adding the TotalPages global to a header (presumably to force an actual count?). I haven't tried this myself, but it may help you solve the issue.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
EDIT : I completed this project using ABCpdf. For anyone interested, I love this product and their support is A+. Everything I listed as a 'Con' for the HTML -> PDF solution was easily doable in ABCpdf.
I've been charged with creating a data driven pdf report. After reviewing the plethora of options, I have narrowed it down to 2. I need you all to to help me decide, or offer alternatives I haven't considered. Here are the requirements:
100% Data driven
Eventually PDF (a stop in HTML is fine, so long as it is converted)
Can be run with multiple sets of data (the layout is always the same, the data is variable)
Contains normal analysis-style copy (saved in DB with html markup)
Contains tables (data for tables is generated at run-time)
Header/Page # on each page
Table of Contents
.NET (VB or C#)
Done quickly
Now, because of the fact that the report is going to be generated with multiple sets of data, I don't think a stamped pdf template will work since I won't know how long or how many pages a certain piece of the report could require.
So, I think my best options are:
Programmatic creation using an iText-like solution.
Generate in HTML and convert to PDF using a third-party application (ABCPdf is the tool I have played with so far)
Both solutions have their pro's and con's.
Programmatic solution:
Pros:
Flexible
Easy page numbering/page header/table of contents
Free
Cons:
Time consuming (to write a layer on top of iText to do what I need and keep maintainable)
Since the copy is already stored in the db with html markup, I would have to parse through the data before I place it into the pdf, ensuring I don't have to break the paragraph into chunks so I can apply bold, italic, underline, etc. to specific phrases. This seems like a huge PITA, and I hope I am wrong about that assumption.
HTML -> PDF
Pros:
Easy to generate from db (no parsing necessary)
Many tools for conversion
Uses technology I am already familiar with
Built-in "Print Preview" - not a req, but nice
Cons:
(Edited after project completion. All of my assumptions were incorrect and ABCpdf is awesome)
1. Almost impossible to generate page headers - Not True
2. Very difficult to generate page numbers Not True
3. Nearly impossible to generate table of contents Not True
4. (Cross-browser support isn't a con; Since its internal, I can dictate what browser to use)
5. Conversion tool quirks - may not convert exactly as rendered in browser Not True
6. Overall, I think it would be very hard to format the HTML exactly as I would want it to appear/convert to PDF. Not True
That's it - I need the communitys help in deciding which way I should go. I might be wrong about some of my Pro/Con assumptions. If I am, please tell me. All thoughts and suggestions are welcome and appreciated.
Thanks
Decided on using an approach similar to the one used at
http://alistapart.com/articles/boom
Using ABCPdf instead of Prince for the eventual HTML -> PDF generation.
Anyone who is interested in the same thing, feel free to message me about this approach.
I think that if you have a full version of Adobe Acrobat Pro, it comes with Adobe Live Cycle. You should be able to produce reports generated from a database from it. It will give you everything you need in formatting since you will create the report from scratch.
You can create a database connection to an OLE database that will feed data to your form fields. You select the tables to be used, any stored procedures that will run, any queries, and then the data will appear on one of the pallettes in the designer.
You can also use Web Services (WDSL) to receive and process commands and return the results to the form.
Either way, you would bind fields to your data source and then the data would be displayed in your form.
If you're willing to do a little .NET work there's this:
http://www.dotnetvj.com/2009/05/populating-pdf-from-aspnet-using.html
Depending on which platform you are using and targeting, you might want to consider a reporting solution. These are not perfect but the one thing they do give you is the ability to write a report once and then render it in HTML, PDF, or even Excel.
Usually they also provide an editor that helps you design the report and make it look just right. They provide things like paging, headers, footers, graphs, etc. They also provide an API that you can use to programatically create and run the reports.
I've used Reporting Services in a MS environment and Jasper Reports in a Java environment with good results in both. I'm sure there are other options but these are the ones I've been able to use successfully.
For the HTML→PDF step, I really love Prince. It looks like you can call it from VB.
My recommendation is to use SQL Reporting Services.
Can design every page & table of your report
Include Header and Footer
Include Page Numbers
Table of Contents
Can span through multiple pages
Supports Images & Charts
Can be rendered to PDF without a need for any thrid party PDF Converters
I am working on a project converting a "spreadsheet application" to a database solution. A macro was written that takes screen shots of each page and pastes them into a PowerPoint presentation. Because of the nice formatting options in Excel, the presentation looks very pretty.
The problem I'm having is that I haven't ever seen an Access report that would be pretty enough to display to upper management. I think the output still has to be a PowerPoint presentation. It needs to look as close as possible to the original output.
I am currently trying to write some code to use a .pot (presentation template) and fill in the data programmatically. Putting the data into a PowerPoint table has been tricky because the tables are not easy to manipulate. For example, if a particular description is too long, I need to break into the next cell down (word-wrap isn't allowed because I can only have n lines per page).
Is there a way to make an Access report pretty, am I headed down the right path, or should I just try to programmatically fill in the Excel spreadsheet and use the code that already exists there to produce the presentation? (I'd still need to figure out how to know when to break a line when using a non-monospaced font, as the users are currently doing that manually when they enter the data in the spreadsheet)
Jason Z:
If I set it to wrap, and I already have n lines, it would make n+1 or 2 lines on the slide, which is unacceptable.
Dennis:
That article looks very good, I should be able to glean something from it. Thanks!
Access has the capability to create downright beautiful reports. The problem is that it can't make a spreadsheet look better than Excel. You have to know when to use each tool.
Use Excel when you have spreadsheet-like formatting, need a lot of boxes and lines, or want to draw charts.
Use Access when you will output a report as a PDF. It's very useful for one-record-per-page detail reports, formatting where you need to position things very precisely, and where you need to embed subreports with related or unrelated data.
Think about the reports that would be nasty in Excel because you'd have to merge cells all over the place and do funny things with the placement and the layout would never work. That's where Access shines.
Joel, (your co-host here) did a thing about using access reports for shipping labels a few years back... maybe this could be a inspriation for you?
http://www.joelonsoftware.com/articles/HowToShipAnything.html
I have implemented Access reports which were 'pretty' enough. The downside is that it takes a lot of time and effort, and trial and error to produce the desired output.
You can definitely get there, but it requires the patience of a saint.
I guess it depends on what you mean by pretty. For example, I do not find it particularly difficult to produce say, reasonable graphs and tables with alternate line shading in Access. It is also possible to use MS Word and fill in bookmarks, or mail merge. If the present system uses VBA to create the PowerPoint presentation, perhaps much of it could be transferred to Access? Microsoft have an article on Access to Powerpoint: http://msdn.microsoft.com/en-us/library/aa159920(office.11).aspx
Finally, it is not impossible to build HTML output from Access.
We create multi-colored, conditionally formated, reports that are printed for the partner meeting each month of a publically traded corporation. They're real pretty.
I would suggest that the problem you're having is because the requirement to replicate the old method identically is an incredibly bad idea.
You're not using Excel any more.
You're using a different tool with different capabilities.
Thus, you will use different methods to get results.
Re-evaluate the original requirements to see if they still make sense (e.g., exactly why is PowerPoint involved at all? Can PowerPoint import from the Access report snapshot viewer? Can PowerPoint import from a PDF produced from an Access report?), or if they are too connected to the old tools, and then determine what is important and what isn't, and only then should you start designing your solution.
I personally would not try to re-invent the wheel here. If you already have an Excel sheet that has the formatting you want, just export the data from Access into Excel for the report. Now, if you didn't have the original Excel sheet to begin with, that would be a completely different story.
As for breaking lines with non-monospaced fonts, have you tried setting the cell format to wrap?
It sounds like the path of least resistance is to fill in the Excel spreadsheet. We have a contractor who does our Access stuff, and for the more complicated reports he uses Excel. I guess complicated == hard to make look good.
Rather than filling in the excel spreadsheet programmatically, you may want to use the external data features of Excel and Access. Generally I put a query on each tab, which of course may be hidden. An "update all" causes all the queries to be updated. Then summary tabs show the pretty results from all the individual queries.
For one particularly complex system, a bit of excel vba programmatically changed a query and then walked through the tabs updating each one.
Finally, rather than doing screen shots, Excel has a "copy cells as a image" copy that populates the copy buffer with a resizeable image. This could give you better looking results than a pure screenshot since a screenshot can have various deficiencies depending on pixel density.
Just an update:
After a few hours of work, I was able to get a nice report out of Access (almost an exact copy of the excel version). It wasn't as difficult as I thought, I just had to figure the correct mixture of out subreports and pagebreaks.
Working with the wordwrap features of Excel/Powerpoint were a dead end because there could only be a set number of lines per page, period; plus I was too lazy to nail down all the pagination with VBA code issues myself. Like Shelley says, Access shines at report generation.
The output ended up being a PDF (Using Adobe Acrobat Professional). The problem I have left is getting select pages of said PDF into Powerpoint without Powerpoint antialiasing the results for me and making the resulting slide's text fuzzy. I found a couple of articles on converting .snp output to .wmf, which sounds like the way to go on that front.