 | Troubleshooting |
As with any form of troubleshooting, the main goals are first to be able to replicate the problem and second to be able to isolate the issue. Sometimes this sounds easier than it really is. However, keeping this philosophy in mind when troubleshooting will be very helpful. This troubleshooting section discusses solid troubleshooting techniques with regard to Crystal Enterprise rather than specific troubleshooting issues.
Crystal Enterprise systems in a production environment can be quite complex. System components might be duplicated and spread across various servers, and these servers also can span firewalls and DMZs. Throw into the mix a custom-developed Crystal Enterprise Web application and it becomes obvious that the domain of the problem can initially appear quite large. By removing this “noise” from a Crystal Enterprise implementation, most issues can be distilled into one key issue. Many companies have separate development, QA, or test environments. If the problem also exhibits itself in these environments it makes troubleshooting much easier than having to tinker with a production system.
Often the most crucial information regarding problem replication seems too trivial to be verified or checked. Additionally, factors that are taken for granted, or assumed, can raise their heads as essential to solving the problem. So documenting, if possible, all the factors contributing to the environment improve greatly the chances for success. This includes documenting the operating system, patch levels, virus checking systems, disk quota control systems, backup programs, any logs or error reports, and the like.
After documenting and reproducing the problem, preferably in a test environment, you move on to problem isolation where the goal is to simplify the issue. For example, if issues arise when viewing a report instance through a Web application, try to remove the Web application from the equation by verifying that the report instance can be viewed in the Web Desktop or through the Crystal Management Console (CMC). Another tip in simplifying a problem is to remove duplicate services from Crystal Enterprise. For example, ensure that during troubleshooting only one CMS, WCS, Cache, Page, and Job Server service are running. Isolation of the problem usually consists of reproducing it given one set of circumstances and not experiencing it in another. For instance in this scenario, seeing a problem when viewing a report with the Web application but not with the Web Desktop indicates an issue with the Web application.
When you troubleshoot Crystal Enterprise, having Crystal Reports Designer installed onto the servers where the Page and Job Servers reside provides tremendous value. Often, when a scheduled report fails in Crystal Enterprise, the properties of the instance display the infamous statement: Cannot open SQL Server. This is a very generic statement that can mean a multitude of error conditions.
With Crystal Reports installed on the Page and Job Servers, the report can be run interactively in Crystal Reports so a more meaningful error message can be viewed. If a report doesn't run correctly in Crystal Reports on the physical Job Server, there is certainly no chance of successfully scheduling the report in Crystal Enterprise. Should a report not run in Crystal Enterprise, you should run the report on the Crystal Enterprise server machine within Crystal Reports as your first step. If the report runs, you can look elsewhere for issues.