cViewSERVER Testing, Installation and Troubleshooting

cViewSERVER allows you to schedule your Crystal Reports. You can use it to determine who gets what report, with what parameters, and when.

It's very easy to use. But sometimes, folks have problems they attribute to a flaw in cViewSERVER. The information here will help you solve those problems.

See below for troubleshooting.

Theory

CViewSERVER is our service-based report and file management program.  It has been developed to provide the following functions:

• Load and process your Crystal Reports
• Schedule reports for automatic distribution
• Process a report via a multirun feature  
• Store parameter values and email addresses in an external list
• Change the location of the data source via our table mapping feature

CViewREMOTE is the manager tool to manage, modify and monitor the schedule information in cViewSERVER and cViewREMOTE schedules.

Installation

First, install the software (trial version). You can find that via a link on the Pricing page. When you get your license file, simply copy it to the same directory where you installed the trial file.

CViewSERVER and cViewREMOTE require the following steps to install correctly.

Troubleshooting

The information here will help you solve problems you have with your cView installation.

Problem #1: cViewSERVER produces a runtime error.

Analysis: You have a version mismatch.

Solution: Install the correct version of cViewSERVER for the Crystal Reports version you are using. Note, if you are using Crystal Reports 9.0, you should upgrade all of your reports to the 9.0 format.

Problem #2: We need to send a single report to a group of email recipients. While trying to schedule in multi run, cViewSERVER required a parameter to make this happen. But, the report does not have any parameters!

Analysis: The design of the multirun is to run a report repeatedly, changing one or more parameters for each run. The expectation is that each run of the report is to go to a different email address. Some people use this to create different disk files, or even to send each run to a different printer.

But, it’s still driven by a parameter. If you “multirun” a report that doesn’t have a parameter, each run will have the same output, so it would be more efficient to just do it once, and then copy that output to the different locations.

There is a variation on this. It is also possible to multirun a report and use the table map feature to specify a different Db table for each run.

This is a specialized feature usually used by those with file based databases where each run requires a different DBF file. 

Solution: If it is the record selection formula you want to change with each run, you cannot do this inside cViewSERVER. The solution to this is to create a parameter in the report, use that in the selection formula and control the parameter value from the multirun.

Problem #3: My CFO wants the monthly cashflow report delivered in Excel format, and my COO wants it as a PDF.

Solution: No problem. Use cViewSERVER to schedule this once as an Excel and once as a PDF. You do not need to set all reports the same way or even one report the same way.

Problem #4: Since I began using cViewSERVER to distribute reports, users are saying the reports are really slow.

Analysis: cViewSERVER is not the problem. File size and transfer rates are the problem.

Solution: We already know cViewSERVER is not a bottleneck for report performance. So, the problem lies elsewhere, and it will be in one of two places.

1.  If your report file is very large, it will slow down the display and printing of the report. It may completely overwhelm the RAM in the video card and cause refresh problems when you scroll through the report. Your network may also have insufficient bandwidth for the large file. Good report design overcomes this. First of all, don't send the source data with the report! Second, try a good Crystal Reports book. You cannot go wrong with the Peck series. Using subreports, for example, reduces the amount of data transfer demand.

2. If your reports seem slow no matter what, the problem is in the local machine. Check system resources from Task SERVER, and see how much RAM you are using. You may need a RAM upgrade. Other causes include too many programs loaded and resident in memory, Microsoft Office Find Fast is on, disk defragmentation is running in the background, hard drives are excessively fragmented, and so on. You may need to evaluate the machine.

Problem #6: Report recipients are complaining the reports don't give them the right information, but I never got these reports before installing cViewSERVER. Is this product somehow corrupting my data?

Analysis: Users who infrequently get reports tend not to depend on them. But, once you are sending reports on a regular schedule, they become important (as does the report designer!). This is a perception problem. In the past, you may have gotten away with reports that are not what they should be. Count this as a job security blessing, because the reports now are seen as the important business asset they are.

Solution:  Find out what end-users really need, and make sure you have good reports on file. Good report design requires forethought and attention to certain rules of design, but it also requires keen attention to the purpose of the reports and what the users need for those reports to be useful.

• The fault could be yours--and thus you can correct that just by designing better reports (see the Crystal Reports books referred to above).

• Or, the fault could be someone else's and much harder for you to correct. See our free articles for Crystal Reports administrators for help with these issues. If you are really stuck and these articles don't help, contact us for a custom consultation. Rates vary, depending on the situation.