Crystal-Reports-Bericht: Fehlende Parameter-Werte

Das problem scheint auftreten, weil Crystal Reports nicht beibehalten werden, die die parameter Werte in die ViewState, wenn ein postback erfolgt. Also, wenn die CrystalReportViewer versucht zu laden, bis die ReportClass es als ReportSource wieder, die Werte der parameter sind nicht mehr da.

Einer Lösung, die wir verwendet haben, erfolgreich ist, speichern Sie die ReportClass (d.h. der Crystal Reports-Objekt) in Session nachdem alle parameter-Werte gesetzt wurden, & dann laden Sie diese in die CrystalReportViewer bei jedem PostBack in der Page_Init Veranstaltung. Ein Beispiel:

//instantiate the Crystal Report
var report = new DeliveryLabelsSingle();

//set the required parameters
report.DataSourceConnections[0].SetConnection("DBServer", "DatabaseName", "DatabaseUser", "DatabasePassword");
report.SetParameterValue("@Param1", "val1");
report.SetParameterValue("@Param2", "val2");

//set the data source of the viewer
crvLabels.ReportSource = report;

//save the report object in session for postback binding
Session["rptDeliveryLabels"] = report;

Dann der Page_Init-Ereignis der Seite sieht wie folgt aus:

protected void Page_Init(object sender, EventArgs e)
{
    if (IsPostBack) {
        if (Session["rptDeliveryLabels"] != null) {
            //cast the report from object to ReportClass so it can be set as the CrystalReportViewer ReportSource
            //(All Crystal Reports inherit from ReportClass, so it serves as an acceptable data type through polymorphism)
            crvLabels.ReportSource = (ReportClass)Session["rptDeliveryLabels"];
        }
    }
}

Wir auf diese Weise wird immer ein report-Objekt für die Zuschauer, die bereits initialisiert wurden mit den entsprechenden Werten.

Etwas zu beachten bei dieser Methode ist, dass Sie potenziell füllen Sie Ihre server-Speicher sehr schnell, vor allem, wenn Sie viele Benutzer eine Vielzahl von verschiedenen berichten. So einige Zimmerreinigung ist in Ordnung. Wir haben dies getan, durch die Implementierung einer Basisklasse für alle unsere ASP.NET Seiten, auf die ein Bericht (und damit auch dieser Bericht be-code). In dieser Basis-Klasse, setzen wir alle möglichen Session Variablen, die Berichte zu null. Etwa so:

//class definition for ASP.NET page containing CrystalReportViewer & associated report(s)
public partial class DeliveryLabelPrint : BaseReport

Dann die definition für BaseReport ist wie folgt:

public class BaseReport : System.Web.UI.Page
{
    protected override void OnLoad(EventArgs e)
    {
        if (!IsPostBack) {
            for (var i = 0; i < Session.Count; i++) {
                var sv = Session[i];
                //if this session variable contains a Crystal Report, destroy it
                if (sv is ReportClass) {
                    sv = null;
                }
            }

            base.OnLoad(e);
        }
    }
}

In dieser Weise ist sichergestellt, dass jeder Benutzer immer nur hat ein Bericht in der Erinnerung zu einem bestimmten Zeitpunkt.

Wenn der Speicher ist ein Anliegen, das auch mit diesem Ansatz eine alternative könnte sein, die zum speichern der einzelnen Werte der Variablen in Session & dann instanziere einen neuen Bericht in Page_Init & bevölkern es mit den gespeicherten Werten, bevor die Zuordnung zu CrystalReportViewer.ReportSource. Aber in unserem Fall, mit 40 Benutzer ziehen 50+ verschiedene Berichte auf einer täglichen basis, diese Implementierung der Speicherung der ReportClass object & die begleitende Haushalt, haben wir nicht die keine Speicher-Probleme, da die Anwendung live gegangen vor 3 Jahren. Ich würde noch vorschlagen, tun entsprechenden load testing & überwachung, bevor Sie diese Lösung, um die Produktion, wie die Ergebnisse variieren je nach der spezifischen Implementierung.

InformationsquelleAutor Carl Heinrich Hancke