Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Report documentation input?

Status
Not open for further replies.

ellet

Programmer
Dec 16, 2004
5
0
0
US
Hello,

I'm hoping for some input regarding what people have found successful when documenting reports. I've seen both ends of the spectrum: detailed functional and technical specifications, versus documenting the report in the .rpt object itself with a text field containing the Report Selection criteria or the SQL statement WHERE clause. I'm personally not supportive of either extreme. Often the detailed, lengthy specs take longer to create than the actual report and are not maintained over time. On the other hand, using query language seems woefully inadequate (no information regarding required columns, layout, formatting, etc) and is difficult for the average user to understand.

Using 3rd party documentation tools is not an option because much of our business logic is embedded in database stored procedures which are either the report datasource or create summary data-mart-like tables.

Any thoughts, suggestions, or examples are greatly appreciated!

~E
 
I have a standard 'template', not in fact a template in Crystal's sense of the term, simply a basic report that I usually start from, using [Save As] to make a working version.

I use a formula field that says "End Of Report" and also has comment fields which document what the report does, when this is non-standard.

We also produce specifications as Word documents when the report is for wider business use and its functions need to be explicitly recorded and maybe changed. Mostly this involves writing the Crystal first, finding the best way to do things and then writing a summary from the code, along with a sample of output. This would be bad practice with some languages, but Crystal is so easy to develop and change that it's the best way.


[yinyang] Madawc Williams (East Anglia, UK). Using Windows XP & Crystal 10 [yinyang]
 
If you are using stored procedures for your business logic which is not available to Crystal, then you are right that 3rd party tools will not do the job. However, they will certainly give you a good starting point. There are several which we have tried, and ended up using Report Miner. It does provide some flexibility in selecting what to include (you could select only the report layaout and report objects within each section in a table format, for example).

Using this as a starting point may be no different that the template apporach suggested in the previous post, but perhaps gives you a starting point closer to where you need to end up with at least a good portion of the data formatted and available.

Rob
 
Hello All,
Crystal Reports has a built in documentation tool. It is called "Report Definitions" it can be found under the "Export" options.

If your report writers have been diligent about adding comments to all formulas, the comments will show up in the Report Definitions.

Once the report is completed I usually take a screenshot of the Design View then print out a hard copy of the report along with a copy of the report definitions. This provides the client with a very good documentation of the report.

I have a couple of wishes for BOBJ.
1. Allow us to print the Design View from within Crystal Reports.
2. Be able to create a report from the Report Definitions. (That I would pay good money for)

Hope this helps.

Regards,
Michael
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top