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.
Related
I was wondering if anyone had a method of running a report to see what a user is doing in Epicor or what they are printing. We are having users report that in the middle of the night, when no one is here at the plant, there are 500 page reports being printed. We are able to see in the print queue who printed what, but the report doesn't match up with anything in our system. We would have for example a report called DailySales.rpt, but in the printer queue it would be something like hb986a87dthr.rpt. Just wondering if anyone else has seen this, or would have a solution that would let me see what a user is printing.
It is not possible to link the print job directly to the SysTask record because neither the print job number, the temp file, nor mac addresses are saved in Epicor for cross referencing. It can be approximated by looking at runtimes and the SysTask record.
You can create a BAQ and BAQ report to display Active and recently completed SysTask information by user. This will give you the report run, start/end times, user, and current status. If you need more detailed information such as the criteria used in the report, you can also join to the SysTaskParam table. Keep in mind that the SysTaskParam table is fully normalized by field name, so you may want to join multiple copies of the table with specific criteria if you need a lot of information. Unfortunately, for "print all pages" jobs, Epicor doesn't know how many pages the report will be until after the data is instantiated and then it is rendered in the reporting software, so you won't be able to get any estimate of number of pages or size.
There are many strategies for mitigating the issue you described. Here are a couple:
You can use criteria within the BAQ to limit the number of records returned for a specific query
You can create a subquery criteria from BAQ parameters to return no data when abnormally open parameters are used for the report (e.g. > 30 days range). You could also use this method with time gates based on the current system time.
Retrain users
I want charts generated for each group to appear in a multi-column format in one group header. I could do it with subreports, but I'm looking for a solution that doesn't require me to load the data set multiple times. How can I achieve this?
Long story short, Crystal isn't a good fit for this.
Even if the number of groups wasn't variable, Crystal reports is fixated on delivering and iterating your records from top to bottom. It's not impossible to structure that, but it would be way more work than it's worth. Plus you'd waste too much time handling the variable number of charts and ensuring unused ones were suppressed. And even then, you'd probably need to use subreports.
You'd have better luck using something other than Crystal for generating this behavior. Even if it meant creating a subreport for the chart and writing a VS program that displayed that report multiple times for each "Group".
I have a fairly straightforward Jasper Report that uses Grouping for up to 8 groups. When I run it, it correctly groups and prints, but each group is on a new page. Although there are several SO and other questions that ask this same thing, I have not been able to get this to work.
What I want is exactly what I have now, but instead, for each group to lay out horizontally on the page.
The report property "print order", which several people allude to, is not changing this behavior. And when I tried setting "columns" to 3, it simply takes the first group and spreads its data over 3 columns, and then starts the next group on a new page.
I have tried every other combination of parameters that might prevent this, but without success. Does anyone know if I can show the groups horizontally across the page?
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.]
In Crystal Reports, is there a way to get both full set charting and subset charting, in the report headers?
I'm working on a report from an erstwhile co-worker and I'm still trying to make things "better".
While I haven't found the solution to accruing time
( see Accruing over time (non-overlapping) - technique? )
I'll press on with how to use the resulting data once I retrieve it.
The report is a Global Availability report for network technologies, and part of the report is graphic:
Chart availability for different
network types for last "n" months'
time.
Charts availability for each region
(for each network type for "n"
months' time).
She (co-worker) had a global chart, but for each region, she did a separate sub-report containing just the chart for that region. The query isn't optimal, and using the sub-reports, the query is repeated each time.
If there a way to use a single data-set in one report for all five charts, forcing the four regional charts to display only that region's data?
Additional info:
The charts are all Bar charts, design is
y-axis: calculated availability
x-axis: Group by network type (Switches, Trunks, "Network)
sub group by month
Bad Example:
Let me see if I understand this. In your Report Header, you have 5 Subreports for the 4 regional graphs and the global graph. And you want to collapse this all into 1 Subreport if possible?
Yes, but you can't do it like in your image where United States & Europe are side-by-side. They would have to be 1 per row. Also, the datasource also has to be formatted correctly. To do this,
Make a new subreport. Group it by the Region.
In this subreport, make your regional graph in the Group Header section.
In this subreport, also make your global graph in the Report Header section.
Insert this subreport into your main report and you should be done.
Sometimes, the only way out of the fire is through it.
After lots of un-satisfactory refactoring, I spoke with the original (years ago) requestor and got some good information. I have yet to speak to the most recent requestor again (who didn't have any knowledge of the technical requirements the last several times).
Spoke w/ the guy who is tending a related db, and I get permission to add come functions, views, store procedures, etc. to THAT db... Within reason and after code/perf review -- something that isn't normally conducted, so I welcome it. I WILL have the ability to do the procedural stuff through... a procedure. Written as a stand-alone, I should be able to re-use it for any of the queries against future needs.
And... Yes, I am pretty much going to have to (read "get to") re-design, and hopefully get rid of most of the sub-reports. Yeay, me.
Thanks for coming along for the ride.