Skip to Content

To state the obvious, Crystal Reports being a database reporting tool, the number one issue concerns database connectivity followed closely by printing and exporting. In this blog I want to describe basic troubleshooting steps, mainly concentrating on database issues.

1) Make sure the report works in the Crystal Reports (CR) designer. If it does not work in the designer, or if the report does not do what you want it to do in the designer, it will not do it at runtime. For example, if you experience issues logging on to a new datasource, can you actually change the datasource in the CR designer? If not, you are not looking at a runtime issue and need to figure out why you can not change the datasource in the designer.

2) Do not big bang your project. Particularly if you are new to Crystal Reports. Start small, work your way up. For example, if you are running a report with a subreport and you have issues connecting to a database. Try a report with no subreports first. If that works, try the subreport on it’s own as a report. Work your way up. I often see database logon issues because a different connection type is used for the main report and subreports. E.g.; main report uses ODBC and subreport uses OLE DB. Invariably this will lead to connection issues if only an ODBC connection is used.

3) Do use as many resources as possible before obtaining support. Developer files ship with each version of Crystal reports and or are available on line. See this blog for useful links for each version of Crystal Reports:

My most frequently used Crystal Reports SDKs support links

4) Use the Developer forums:

http://www.sdn.sap.com/irj/sdn/businessobjects-sdk-forums

Search the forums for similar issues before creating a new post.

Search the notes (kbase) database:
http://www.sdn.sap.com/irj/sdn/businessobjects-notes

Search the articles (White Papers) page:
http://www.sdn.sap.com/irj/sdn/businessobjects-articles

The advanced search on the articles page allows for key word searches.

Search the downloads page for resources such as sample apps, Service packs, merge modules, etc.;
http://www.sdn.sap.com/irj/sdn/businessobjects-downloads

Search the Wiki:
http://www.sdn.sap.com/irj/sdn/wiki

Search the Blogs:
http://www.sdn.sap.com/irj/sdn/weblogs

5) Work with the latest Service Pack and ensure that the runtime you are distributing matches the runtime on your development computer. A great utility to check for possible dll version differences is Modules.exe. Modules can be downloaded from here:

https://smpdl.sap-ag.de/~sapidp/012002523100006252802008E/modules.zip

6) Make sure your application works before you deploy it. If it does not work on your development computer, it will more than likely not work when you distribute the app to a production environment. I have, on occasion seen this strategy being employed as a way of increasing the severity level of the issue. This scenario would not qualify as a “High” priority level issue, though.

7) Test your app on a staging system before deploying to a production system. Going straight from a development system to a production system is not an advisable strategy. Once again, this strategy should not be used to increase support severity level.

8) If you are using a web application, try a simple windows application. If a win app works, and web app does not, generally the issue is related to permissions. A few great utilities to troubleshoot permissions are:

Filemon:
http://www.microsoft.com/technet/sysinternals/utilities/filemon.mspx

Regmon;
http://www.microsoft.com/technet/sysinternals/utilities/regmon.mspx

Process Monitor:
http://technet.microsoft.com/en-ca/sysinternals/bb896645.aspx

Fiddler:
http://www.fiddlertool.com/fiddler/

Charles:
http://www.charlesproxy.com/

9) If you are having issues with a deployed windows application (but this may also apply to web applications), check to see that you are using same version dlls on the deployed system as on your development computer. A great tool to compare dlls is Modules.exe which can be downloaded from here;
https://smpdl.sap-ag.de/~sapidp/012002523100006252802008E/modules.zip

10) Deployed web application’s runtime is also good to check with Modules.exe, particularly if you are seeing errors or behaviors on the deployed server that are different from your development computer.

11) It is always critical to use the correct runtime when deploying your app. For more information see my Wiki post here:

https://wiki.sdn.sap.com/wiki/display/BOBJ/Crystal+Reports+for+Visual+Studio+.NET+Runtime+Distribution++-++Versions+9.1+to+12.0

Also note that all versions of Crystal Reports ship with good developer help files that contain details information regarding runtime and how to deploy applications that use Crystal Reports.

12) If your application works in a development environment, but fails once it is distributed, ensure that your database client is installed and that it matches your development environment.

13) Be careful when reading other people’s suggestions towards resolving an issue. Just because the error is the same, does not mean the underlying problem is the same, particularly if the error is for a different version of Crystal Reports. E.g.; just because your car will not start because the battery is dead, does not mean this is the cause for all cars that will not start.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply