Hello all,
I'm wanted to open a thread that discusses large reporting packages. Below are thoughts I have and I am hoping others will contribute links that discuss this, best practices, lessons learned, gotcha's, etc. I've read a lot of resources about the technical aspects of Crystal, but can't find anything that deals specifically with packages.
We need to develop a very large reporting "Package" that has these requirements:
-Multiple reports with different databases in some cases
-2 or more report developers
-Must look consistent
-Table of contents with page numbers
-Must be able to be refreshed from a single refresh button.
We are considering the use of a shell main report (just logo's, etc) that uses sub reports merged into it for these reasons to name some.
-Can split different parts of the work to different people
-Makes the larger report easier to understand
-If one report is a different data source, a sub report can eliminate the issue of losing SQL expressions if it uses the one data source (normally SQL expressions are lost when a report uses different data sources in one report)
-Can "Save As" an embedded sub report out of the main report if needed solo.
-Can apply a standard template to each sub report for consistency.
Problems
-Sharing parameters across the sub reports has proved complicated, though possible.
-Sub Reports cannot have Sub Reports as I understand it.
I'm wanted to open a thread that discusses large reporting packages. Below are thoughts I have and I am hoping others will contribute links that discuss this, best practices, lessons learned, gotcha's, etc. I've read a lot of resources about the technical aspects of Crystal, but can't find anything that deals specifically with packages.
We need to develop a very large reporting "Package" that has these requirements:
-Multiple reports with different databases in some cases
-2 or more report developers
-Must look consistent
-Table of contents with page numbers
-Must be able to be refreshed from a single refresh button.
We are considering the use of a shell main report (just logo's, etc) that uses sub reports merged into it for these reasons to name some.
-Can split different parts of the work to different people
-Makes the larger report easier to understand
-If one report is a different data source, a sub report can eliminate the issue of losing SQL expressions if it uses the one data source (normally SQL expressions are lost when a report uses different data sources in one report)
-Can "Save As" an embedded sub report out of the main report if needed solo.
-Can apply a standard template to each sub report for consistency.
Problems
-Sharing parameters across the sub reports has proved complicated, though possible.
-Sub Reports cannot have Sub Reports as I understand it.