I have an RDL report built in Business Intelligence Studio 2008 and I am having an issue with an unwanted page break.
I have a single dataset with a singletable with some summed data. I have added in a List and added two groups.
I have even checked the page break properties of each one.
The report works fine, but my top most group seems to page breaking, leaving extra pages in the beginning.
What I would like to happen is to have the top most group be a page header, and the second group to be a group header for the detail. Am I going about this the wrong way?
Some things you can look at...
Check your report Properties - Look at Consume Container WhiteSpace >
Set it to True
It looks like you are checking the Tablix page break. Did you right
click on each of the Row Group > Group Properties > Page Break
Options Between Each Instance of a Group?
Another issue could be the margins (make sure they are set to inches
if that is what you use). Make sure that your Margins + Report body
is less than the printing area you are attempting to print on
(screen/pdf/paper/etc).
Using '&' for string concatenation instead of '+' (don't know why but
this sometimes causes page issues).
Check can grow settings on your cells
Print destinations settings > properties > check "Override Default settings"
Check the white space around your report body (attempt to minimize any if you can)
Here is some other useful info about Pagination from MS SQL Server
I had a tablix with "Keep Together" marked. The tablix also showed a subreport for each row. It turned out that the first record had a very long subreport so it could not fit on the page w/ the top of page elements I had (report title).
this took me the better part of an afternoon before I realized what was happening.
ultimately i lived with it. I wanted the keep together feature. Next week, a shorter record will be the first one and it wont be an issue.
Related
I'm using the new fixed page layout report in active reports 7, with a fixed cover page and a variable number of overflow pages. When it's printed the user can select a number of these reports to print at once, and the data for the report is adjusted accordingly. The report has grouping defined to start a new cover page for each group. How can I ensure that when printing to a double sided printer that each cover page is printed to a new sheet of paper? For example, consider the simple case where there is only a cover sheet and no overflow. If the dataset contains data for three such pages, how can I ensure that a new sheet is printed for each one, rather than the second being printed on the back of the first?
An alternative solution would be to split the data before it gets to the report, then repeatedly create and print the report for each group. To do this I would need to ask the user to select a printer for the first copy, but then use the same printer for subsequent invocations. How can I determine which printer the user selected, then pass that printer to the second, third, etc invocations? I could create my own printer selection dialog, I guess, but it would be useful to know if I can retrieve the information from the built in one
I don't think there is any way to do this with AR currently. It's a great idea though and I'll make sure the ActiveReports team considers this in the future. I'll also ask around and see if anyone else has ideas within GrapeCity/ComponentOne.
I've looked all over and cannot find an answer to my question; I can't even determine whether it is possible.
Referring to the attached image, you will notice that this is a statement report with data grouping activated.
1) The report shows all the services invoiced to an account by date.
You can expand the group to see all the transactions that formed part of that service for that day. (You can for instance make use of the same service multiple times per day)
2) This is the detailed layout of the service invoiced. This list is different for each service, but mainly it will show you a summarized transaction list (PK BatchId), which has the "+" symbol next to it to enable drilldown to a detailed report of the batch.
My problem:
When loading the statement report, we are now hitting multiple tables, multiple times to produce the data to be grouped and displayed in #2 (refer to image).
We are trying to avoid this like the plague.
My Question
Is there a way to populate #2 when and only when the user clicks a "+" symbol or an "expand" image where the "+" is currently located in #1.
In other words. We dispose of the group function and populate the statement without detailed information. When the user clicks on #1, we load a sproc, populate a dataset and display the data in #2.
Any thoughts on this?
Drillthrough Reports look like a good solution here. See the link for more information on how these work. So basically you have the report without the detailed information, but when somebody clicks on 1 it opens up a new report with the details behind it.
After testing, I confirmed that subreports are executed even if they are hidden within an element that can be toggled.
So subreports won't answer this problem.
[Edited: previously I thought they could be used. JAT points out that this negative answer may have some value, so I'm leaving it.]
Hopefully this is simple enough that someone can help. I have a simple row oriented report.
The problem I have is the Keep together command is chosen on the detail lines, but sometimes the detail lines will go over to the next page. There are usually 4 or 5 detail lines before the next group starts.
If there are more detail lines than will fit on the page, what I want it to do is a page break and start over showing the group header #1 (simple report with one group) and then start printing the details again.
So, what would the necessary formula be to keep the detail lines together? Why doesn't keep together keep together?
It sounds like you want to select Keep Together on the group, not the details section. (Group Expert -> select your group and hit 'Options' -> 'Options' tab -> select 'Keep Group Together'). Selecting Keep Together on the Details section only causes that single row to not be split up (this is the default behavior, as far as I know).
I'm not 100% off the top of my head, but if there are more details than will fit on the page I think it will behave as you want; page breaking before the group starts and then continuing onto a second page.
I guess you marked Keep Together on each Details section, which keeps each section from spliting not all of them.
Try checking it on Details general section in Section Expert.
Check this screen shot to see how:
I have been asked to mock up a report in Crystal (i would normally use SSRS but the application uses crystal for report), and i need to split the page up into thirds. The idea is that the top 2 thirds are for the customer, then there will be a tear line on the paper and under that will be the section for us to keep.
What is the best way to accomplish this, baring in mind the report could go over 2 pages?
Cheers
Luke
Based on my understanding of the requirements, you just want to space things out over a customer's order (or something similar). I am assuming the grouping will be by customer with items in the details sections.
1) If all fields required are in a single records, and you can stick by the "2/3's page" visually, you can force the spacing simply by extending the reporting band sections. i.e., Increase the page header and include some customer information, or do the same with a group header, etc. and then space out a single details band with fields spread out as is visually pleasing.
With the spacing done this way, you can also embed a small band that holds only a dashed line, which will be a visual tear line.
Fields placed in the next band will be the portion that you intend to keep.
2) If the customer section will have multiple items in details -- be smaller or larger (i.e., if you are pulling in an inventory list that may have 1 or 21 items), then you can still something similar, but not using enlarged, fixed band sizes. You can put customer general information in a group header, followed by multiple details (records), and end with a two-band group footer. The first band can be any closing information for that customer, followed with a visual tear-bar, and the last band can be the information you wish to keep.
Grouping by customer and forcing new pages for each customer should give you what you're looking for.
I hope that's clear enough to give you two alternatives.
D'Oh... and, forgot to include: You can use the Section Expert to format a group footer to Print At the Bottom Of Page, forcing the portion that you want to keep to the lower part of the page. On a multi-page printout, it would be forced to the bottom of the nth page.
I have a report with 4 seperate sub-reports embedded into it.
On the main report, I have a parameter to filter by group and I have it set to filter by group unless you choose All for the parameter, then it shows all groups.
If {?Main Group Name} = "ALL" then {Incident.Group Name} like "*"
else {Incident.Group Name} = {?Main Group Name}
This filter setup works fine on the individual sub reports, however if I run it selecting "all" as part of the main group, it causes the sheet to loop indefinitely and doesn't show the data properly.
The data is in all Group header 1 and group footer 1, so ideally the same page(as below) should repeat for every group.
When I run it for all, It runs for an abnormally long time, and has to be manually stopped, otherwise it just keeps going. After manually stopping, I get the following. It almost looks like it's trying to render all the groups on top of each other.
Anyone have a clue what could cause this?
Where are your subreports located in the main report (group header)? What are you doing with the record details of the main report (suppressing, I'm guessing)? What do the record selection formulas look like, FROM the subreports? How many tables are in the subreports? If multi-table, are your joins correct?
I have seen occurrences when subreports have a given Record Selection, and then have links added from the main report, where the resulting subreport query is totally hosed as Crystal Reports "helps" by modifying the subreport record selection on top of what the developer intended. True Story (a 17 second report was updated and ran for 20 hours before anyone noticed it had never finished a scheduled run). It sounds (heh, in inter-text) like you don't have correct relationships set up in the subreports, and may actually have cartesean products being formed.
Where are you using your code shown in your question? In the Record Selection? In an #Formula? What kind of link are you using to the subreport? What "should" be linked to the subreports is the {Incident.Group Name} -- as that is what changes in the main report group.
If you break out the subreports, and run them individually, manually setting the {?Main Group Name} to "ALL" and then to sample group names, what is the result? If the individual subreports still run on, you can at least watch the record counts (status bar) and when you manually kill the report, you can look at the performance information, and at the subreport Show Query.
Lastly, if you try running the main as "ALL" using a Top 10 (or 2, or whatever number you want) and then watch the subreport performance, that might give some clues. If there are selection-hosation byproducts, this would at least limit the effects a bit. You'd still be passing "*" to the subreport, but only doing it "N" cycles.
Sigh, and one last: If you really want "all", you might be better served if you use something like:
If {?Main Group Name} = "ALL" then TRUE
else {Incident.Group Name} = {?Main Group Name}
Sorry to be so long... I didn't have enough time to shorten it.
OK, really, really LAST one: If I have misunderstood your post, assumed too many disparate themes, or am just talking out of my hat: Sorry. Missed a meal, picked up several interruptions, and doubled up on the coffee. I'm sure there's a smiley for that, somewhere.
[Inserting add'l answer, as it is distinct enough to warrant it's own entry.]
I think I understand the Group Header/Foot Charts.
Did you try running Main as a Top 10 to limit the # groups?
How big is the (chart) record set?
AND, is the report set up for asynchronous queries?
What IS going on in the subreports:
Complex query?
Simple query?
Suppressing all Details and just showing the Chart?
Going to a different table/database?
Table joins?
Run for "Top 10" Groups in main, wait until it ends, then check for the Main and each chart sub (for at least a few groups):
Report / Performance Information:
Total Number of Records -- (Main should be "Top 10" )
Performance Timing:
Run the Query,
Read Database Records,
Time to Format All Charts
or
Time to Format 1st Page.
If you have several millions of records, even with "top", it could take a while to read and calculate the top. If you are calling charting, even tho' it is for a single Group per chart, if the subreport still has to apply a linked query, parse millions of records, perform add'l calculations, create a chart (that still accounts for all records), etc., it can just be a long time running.
You may find that a small "All" Top "n" will show a lot of time being spent behind the scenes, and that allowing the whole report to run that the add'l Comparison of Ticket Counts is displayed. And if not, we can look at that later (mainly by opening up the corpse and looking inside).
I am trying to ascertain regular behaviour, and I can't get a requirements doc for review. I can only make assumptions and ask questions and make suggestions.