Report Design
 Crystal Reports Forum : Crystal Reports 9 through 2020 : Report Design
Message Icon Topic: Subreport overflow Post Reply Post New Topic
Author Message
dustbun
Newbie
Newbie


Joined: 19 Jan 2009
Online Status: Offline
Posts: 4
Quote dustbun Replybullet Topic: Subreport overflow
    Posted: 20 Apr 2009 at 9:02pm

I am working on a challenging report in Crystal 10.  The purpose of the report is to show a main record, it's information and associated child records. Each page is designed to be a snapshot of the main record and one of the child records, including graphics. There will be multiple main records and there can be any number of child records, ranging from 0 to hundred.

I have the report grouped by main record and then child record.  Because of the nature of the records, this report has several subreports.  The design of the report contains several subreports relating to the main record in the group1 header, a band of child record information in the group2 area and then more main record subreports in the group1 footer.  Due to the amount of other data on the page, the number of records on my subreports cannot grow any further than I have them scaled.  For instance, one subreport displays 4 records, another might show 10 records, etc.

 
The challenge is overflow from the subreports. I am tasked with providing as much of the data from the main record as I can on the first page (first child record). The second page (second child record) should show the next set of main record information, etc.  For instance:

Page 1
GH1`Sales Info Records #1 - #5 (2009, 2008, 2007, 2006, 2005)
GH2 Child record #1
GF1 Purchases Records #1 - #10 (2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999)

Page 2
GH1 Next set of Sales Info Records #6 - #10 (2004, 2003, 2002, 2001, 2000)
GH2 Child Record #2
GF1 Next Set of Purchases Records #11 - #20 (1998, 1997, etc,,,)

This is to repeat until the report runs out of subreport records or child records (with a final "can grow" page of the rest of the subreports (purchases and sales).

I have searched and have only found information on check stubs, but this situation is a little more complicated especially with multiple records and pages.  I am not sure how many duplicate copies of teh subreports I would have to create to accomodate the amount of records on each subreport.  My report would take forever to run. Although one copy of each would be fine if necessary. 

Can anyone think of some solution or path for me to follow?      


 

IP IP Logged
lockwelle
Moderator
Moderator


Joined: 21 Dec 2007
Online Status: Offline
Posts: 4372
Quote lockwelle Replybullet Posted: 21 Apr 2009 at 6:15am
What I would suggest is to create a super record in a stored proc. 
 
The super record would be the the info for the GH1, GH2, GF1 (really all the data you need for any column of the report and subreport) all combined.  Now you can limit the number of records displayed by using deletes from the record set and the report will run faster as there are no subreports, so it is only 1 call to the database.
 
If you are not using stored proc/views you might try without subreports, I don't use them very often, I find that I don't need them, that will speed up the report, but sometimes subreports are just unavoidable.
 
IP IP Logged
dustbun
Newbie
Newbie


Joined: 19 Jan 2009
Online Status: Offline
Posts: 4
Quote dustbun Replybullet Posted: 21 Apr 2009 at 6:28am

The application that we get our data from generates text files for each main record and different text files for each subreport.  I would love to use a stored procedure in this case, but can't.

 
 
IP IP Logged
lockwelle
Moderator
Moderator


Joined: 21 Dec 2007
Online Status: Offline
Posts: 4372
Quote lockwelle Replybullet Posted: 22 Apr 2009 at 6:10am
Having had a bit of time to think, the only other way to limit the number of rows per band is to have a counter.  Increment it in the detail section and when it reaches a certain preset limit, have the suppression kick in and suppress the line.
 
It's a thought.  This is the main concern isn't it, limiting the number or rows per band so that they fit on a page?  Just making sure that I am not answering the wrong question.
 
IP IP Logged
Post Reply Post New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum



This page was generated in 0.015 seconds.