Avoid Mixing the Object Models

Do not mix the CrystalReportViewer object model with other object models.

Use of the CrystalReportViewer control in its role as a limited object model works properly, provided you bind the control directly to the report with a simple path string.

But if you encapsulate the report into one of the other object models (such as ReportDocument or ReportClientDocument), and then bind the control to that object model, stop using the CrystalReportViewer object model right away. The limited model that is provided by the CrystalReportViewer control becomes redundant to the more powerful object model that it is bound to. Also, settings that are applied to the CrystalReportViewer object model are visible to the other object model, which could result in unexpected behaviors and exceptions.

For example, you may want to use the ReportDocument object model to export or print a monthly report from the server. If you have set a month parameter on this report with the CrystalReportViewer object model, you may experience problems. The ReportDocument object model cannot see parameter settings applied in the CrystalReportViewer object model. It will try to export or print the report without knowledge of that month parameter setting, and then display the wrong month or even throw an exception.

The best answer is to limit use of the CrystalReportViewer control to report display settings only when the control has been bound to one of the underlying object models.