We have a report which looks like this:
If I then go Actions>Export>Excel I get the following:
Unfortunately the number circled is misleading. This column is a count of users - so if the same user was in several months they should only be counted in the total as 1.
I assume out-of-the-box it adds the excel outline whenever we include the expansion/collapse (+/-) functionality in the report.
Is there a way in the rdl file to stop RS's export functionality of adding the outline?
That Outline behaviour in Excel is triggered by the ToggleItem property in SSRS. You cannot set this with an Expression. Therefore I would remove the ToggleItem property from all textboxes.
Instead I would use Bookmarks and/or DocumentMap functionality - these achieve similar results and generally work better across a broad range of rendered output formats.
Related
I want to do a simple merging of cells in a DevExpress VGridControl. The attached image shows exactly what I need. I have come across a lot of support tickets by DevExpress and all are redirected to just one link of Devexpress Sample E3019.
Firstly this is a very complex process, but even if I use this to merge cells in my VGridControl, the cells are not merged in the excel file when exported.
I had posted this question in the Devexpress Support Forum but did not get a positive reply on the same :
https://www.devexpress.com/support/center/Question/Details/T392883
(Please do not confuse the VGridControl with GridControl - they are two different functionalities used for different purposes)
The below image exactly shows what I want to achieve
I managed to get this functionality in place by first exporting the VGridControl to Excel and then reading the Excel file from C#. We can perform cell by cell operations and formatting using c# - refer the below link :
http://csharp.net-informations.com/excel/csharp-format-excel.htm
I'm attempting to create an excel spreadsheet using BIRT. The spreadsheet is a crosstab mapping two objects together. The number of rows and columns are dynamic based on values in a MySQL database. Currently I have a working implementation of the report for PDF output. Now, I am trying to create a second version of the report for Excel.
I have copied the report design and begun adjusting it to work with Excel. Everything looks good, but only the first 3 columns are displayed after the header. All rows appear correctly.
I have tried the following:
I tried setting Overflow to Visible on every element on the page. This had no effect.
I tried setting the master page's height and width to ridiculously large values. All of the information displayed correctly, but I am hoping for a solution without hard coded values. In the future the data width might exceed my arbitrary value again and be cut off.
I am constrained in the following ways:
I am not able to switch reporting engines (I have to use BIRT).
I am not able to switch Excel emitters.
This blog entry mentions my problem:
http://www.spudsoft.co.uk/2011/10/the-spudsoft-birt-excel-emitters/
but it does not offer a solution other than an emitter switch. The specific quote is "The files also have problems with page layout that I could not work around (specifically wide reports would be cut off)."
Beyond the one blog entry my googlefu has failed me. Any help is appreciated! Thank you!
There are two questions here. The first one is relatively easy, the second is complex.
1.Why is my Cross tab being cut off in Excel?
2.How do I dynamically adjust the master page width based on the number of columns in the report at runtime?
A1: The Cross tab is being cut off because column widths have been manually set, where the number of columns will expand past the set width of the Master page. Anytime you grab report design element and adjust, BIRT assumes you know what your doing and does not override your setting.
The solution is to recreate the report element (Table or Cross Tab) and not manually adjust any sizes. When run in HTML or Excel all the columns will be automatically set to display in the available master page width.
Screen shot of a BIRT 4.2 Cross Tab, Report Item with a 2 inch master page width and 30 columns
A2: This is not easy, and I will not be providing the answer at this time. I will point toward the solution and identify a couple of the road blocks. A valid solution to this question must include a functioning solution using the Sample Database.
(as of BIRT 4.2.1)
Challenge1 - The Master Page Width is set BIRT Report Scripting in events prior to report Table or Cross Tab item being completed. You can not simply count how many columns are in the report;
If you wanted to count, columns --
Report Design intialize
columnCount = 0;
Cross Tab, onCreate
columnCount ++;
In my research there are two paths suggested for counting columns prior to the Cross Tab item being created. Either
Run the data set in the beforeFactory (this means two queries to the data base, one to count and one for the report), then get a count and use it.
Calculate the value in your intial query and harvest it in the Data Set, onFetch.
I followed the Data Set, onFetch, option using a computed column but did not get it working.
Challenge2 - The Width Property of the Master Page must be set on or before the Report Design, beforeRender. With the beforeFactory being the most often recommended. Additionally the Width Property of the Master Page is only available when the Master Page "Type" is set to "Custom", in my attempts I set this manually in the Property Editor General.
Passing Values from the onFetch to beforeFactory must be done using a PersistentGlobalVariable which can only pass strings, not integers. I found all kinds of way for this to not work. Even passing "12in" in PersistentGlobalVariable failed to adjust the master page Width
Either of these codes in beforeFactory will adjust the Master Page Width (when Type = Custom)
Pass the Value
reportContext.getReportRunnable().designHandle.getDesignHandle().findMasterPage("Simple MasterPage").setProperty("width","12in");
Calculate a value and pass it
increaseWidth = 20;
reportContext.getReportRunnable().designHandle.getDesignHandle().findMasterPage( "Simple MasterPage").setProperty("width",((2+increaseWidth)+"in"));
In the end I have been unable to find or create a functional report that adjusts the Master Page Width passed on the number columns generated at report run time. I think it is possible, but doing so is beyond my current skills.
I have a SQL Server Reporting Services report that has several layers of groups. The groups have footers but no headers. Each sub-group's visibility is initially hidden and can be toggled from a cell in the footer of its parent group.
The report renders fine in the browser. However, when I export to Excel the groupings are wrong. With three layers of groups the last item in the second layer is not collapsable in Excel. The last item in the third layer is collapsable but not initially collapsed like it should be and is in the browser.
Is there anything I can do differently to make this work?
I do not have a high enough rep to add comments so I am posting my comment here.
Do you summation expressions in those lines like this.
=sum(Fields!MyField.Value)
I have noticed with excel that it has no way to conditionally represent a summation like the one above when you collapse a group.
This means that the information has to go somewhere, as excel will not truncate information, and is represented by the addition of a line with the summation the same as the =sum() expression in excel.
I am working on an excel report in CrystalReports, in VS2005. I have a field in the Details section which can have up to 255 characters of text, and I want the height of the row in excel to expand so that the entire text can be seen initially when the report is generated.
I set CanGrow=True in the field's properties, and the field does seem to grow; the field is only one line (Height=159), but many of the rows display multiple, wrapped lines of text. Some rows intermittently have the bottem half of the last line of text cut off; the user has to expand the row a little bit to see it. There doesn't seem to be a particular field length that causes this - in one case, it has four lines total in the output, and in another case, it has only three.
Can anyone suggest what might be the cause of this, or how I could work around it?
Thanks in advance for any help you guys can offer.
[Edit: I am no longer working on this project, so I never found out what became of this setting. Most likely it wasn't fixed, since it's not a critical issue.]
One solution to this issue that I've come up with in the past is to have two separate reports. One for display and exporting to pdfor rtf and another report for exporting to Excel.
I know in general this is not a good approach because there is the possibility for data to be different in the export than the display report, but if careful it works well.
I have a situation where a client needs data printed in a specific format on a report, but there is way to much data to physically be able to fit on a page. We worked out a solution that I run a "display version" of the report that fits most of the data, but the rest of the data necessary for there client is added only to the "Excel version" of the report.
To do this I simply load the "display report" to the report viewer as you normally would, but when you go to export the report I load the "excel report" with the same parameters as the "display report" and call the code to export the data to Excel.
By using this method the "display report" can be formatted any way necessary without having to worry about messing up the export to excel. The excel report fields can then be made a smaller size than required by the display report because the data should export even regardless of the size of the field. Doing this allows you to fit more data on the Excel export report.
Since both reports use the same datasource you will have an issue if you make a change that you have to remember to go verify the database on each report to see the new database changes, but this method allows you to include more data and in a different format than the display version of the report.
Hope this helps.
While not a solution for Crystal (I don't know of one), as part of the reporting team at GrapeCity-Data Dynamics, we've worked with similar issues taking free-form reports to excel spreadsheets for a decade. In our Data Dynamics Reports product we came up with a completely new way of solving the problem of exporting reports to excel.
We allow you to create a template for the report output. The template is a basic excel file with place holders for the various textboxes (or other controls) and regions (tables, lists, etc.) in the report. You can open this template inside of excel and modify the properties of the cells and rows. In the scenario you describe, you can export a "template" from Data Dynamics Reports and then modify the autosize property of the row in the template containing the placeholder for the textbox you're struggling with.
When you export the report to excel next time, just specify the template to Data Dynamics Reports (which can be done programmatically and transparently to the end user) and Data Dynamics Reports will honor all settings you specified in the template.
This is hard to explain so there is a ~2 minute screencast that shows this feature at our website in the following location:
http://www.datadynamics.com/Products/DDRPT/ScreencastViewer.aspx?ID=XLS01
For more information about the product and for a free trial download visit: http://www.datadynamics.com/DataDynamicsReports
Scott Willeke
GrapeCity - Data Dynamics
Hi I have a Reporting service report. I am using grouping on the report. My report looks great in HTML rendering, but in excel version the first and the last columns are having extra lines, where that lines are not in html version.
Could anyone please give me a hint , why its so.
Thanks,
Suni
If any controls overlap or are even a single pixel higher or lower in the designer the Excel rendering engine will interpret them as a new row. Use the property sheet to verify that no controls overlap and that the top and height properties for the controls are identical.
Hope this helps,
Bill
I ran into this problem a lot when using report headers, where a company logo or report title was much longer than any of the fields of the report, causing merged cells. There is an option you can set in the config of the report server to use simple headers, as well as limit some of the impact of the misaligned cells issue Bill Mueller mentions. Here is a good example of how to achieve this: http://mysqlserverblog.com/2008/01/03/changing-export-options-for-reporting-services.aspx
i have seen this quite a lot, if people tend to export the report a lot i remove all of the formatting from it, limit the number of groups you can drill down into and do as Bill says and make sure you have no overlapping controls.