I have produced a cross tab report in Crystal reports 2011 based on a SQL database.
Here is a screen shot
Now by default the cross tab report does not seem to give the summarised data any headers, so that my report shows 4 totals in each cell, but does not identify what each total is. I have used a text box in an attempt to place some headers in the report as follows -
However, this does not solve the issue as the text box only appears in the first column, and not in subsequent columns, as the first picture shows.
Is there a way to add headers to summarised data in cross tab reports?
Got it - there is an option on Right Clicking the summarised date, to include Labels, as per the following screenshot -
Related
I am encountering an very unusual behavior while rendering a SSRS report in EXCEL format. I have a simple SSRS report with one parameter (Country).It has only one tablix (table) with no report header and footer. This report will be generated by executing a SSIS package. The SSIS package will pass the country parameter (one parameter at a time) and invoke the data driven subscription associated with the report. Three reports will be generated in Excel format in the specific location provided for each parameter passed. Say, one report for parameter India, one for Pakistan and final one for Srilanka. After the report generation, Sometimes I find that the last row is hidden in any one or all of three reports generated. So, I converted the specification of table height & width, row height and column width from inches to pt as per the workaround suggested by Microsoft. But, it is behaving in unusual pattern after this modification too. Sometimes the report has no hidden last row and sometimes it has. Please note that every time, I have used the same sample data for this report generation.
Also, I have changed below properties of textboxes in tablix as per suggestion in one of the workaround post
Padding - 2pt,2pt,0pt,0pt
Vertical align - Middle
Can grow - false
an shrink - false
And tried increasing the row height from 15pt to 22pt. But above same unusual behavior persists. I have attached the screenshots of report design and sample report here Did anyone experienced this issue before. Any suggestions on this issue will be really helpful.
Report Design
Here row 10045 is hidden
After spending around an hour, I figured out the fix for it.
As mentioned by Microsoft the row height/width measurement has to be in points.
The main part is you have to apply it for all the cells of the tablix. Select ALL the cells and Press F4 to get the properties window and do the required changes in points (shown below).
Note: The default height of excel row is 14.4pt.
I have been facing the same issue, what I did to fix:
1. Converted all the size from cms to pts, page size, report size, columns size, row size, tablix size.
2. It didnt work even after changing row height to 14.2pt, because font was verdana 10pt, and for that minimum 14.3pt is needed in excel
3. I have changed row height to 14.3 pt, and now it works always. No more hidden rows.
Hope this helps.
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 report where I have 50+ fields and I am exporting this report from crystal to excel. Once in excel the data columns are the proper width but the headings are truncated. Is there a way to get the headings to dynamically expand like the data does?
Have you tried using the grid line tools to line up all your columns and headers? Ensure snap to grid is on and that all headers/fields are the same size on screen.
Basically you want the crystal report in the designer to look similar to an excel report; with all the headers and fields in a grid like structure.
Crystal also produced a document many moons ago when they were owned by Seagate describing how to avoid formatting problems when exporting to excel. Check it out HERE
This helped me a load when I had to build stock reports and summaries for one of my customers.
I have a simple Reporting Services report, a simple table, created with BIDS 2005, with the report wizard.
I run the report on a RS2008 R2 server as is and it renders perfectly.
When I export to Excel, an extra row is appended just below the table. The row is hidden and has a heigth of 409.5.
Where that row comes from ?
How to get rid of it ?
*nb - no extra row if run on a RS2005 server
The only way I found to eliminate the hidden row is change the layout of the report. I increased the height of all rows of from 0,53333cm to 0,538cm.
Anything less than 0,538cm doesn’t solve the issue.
According to Microsoft, the goal when exporting to excel is to match the visual appearance of the report as close as possible. The excel output may have unexpected things like extra rows or columns or merged cells as part of the process to match the layout.
Changing the tablix location to 0cm, 0cm , will fix the problem.
I was running into this issue and tried all the posted solutions I could find, but none worked for me. To be more specific, after exporting the SSRS report to excel there was an extra row that contained duplicated data from the first row of the group. This extra row was contained in a group that could be toggled and when that group was collapsed that extra row was still showing instead of nothing.
This was the report layout looked like before I made the change.
What I had to do was add an extra row above and outside the nested grouping by right clicking the group box and selecting "Add row" -> "Outside Group - Above"
Here is the report after.
After adding the rows outside the group there was no duplicated data in an extra row.
Try to change the Size of report(not table) to 0.0pt, 0.0pt.It will automatically set it to minimum required.
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