问题似乎会出现,因为Crystal报告在出现倒退时并没有坚持其观点中的参数价值。 因此,当<代码>CrystalReportViewer试图装上ReportClass时,该编码又被用作ReportSource,那么参数值就不复存在。

我们成功使用的一种解决办法是,在设定所有参数值后,将ReportClass(即:您的Cry Report Object) 替换为>>>Session;然后将其装入。 履历表 <代码>Page_Init中的每一次邮局。 例如:

// 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;

页: 1

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"];
        }
    }
}

这样,我们将永远为观众设定一个报告标语,该标语已经以适当的价值初步形成。

牢记这种做法,是你有可能非常迅速地填补你的服务器记忆,特别是如果你们有许多用户生成大量不同报告的话。 因此,有些房屋保留是按规定进行的。 我们通过为我们的所有伙伴关系实施一个基级,来做到这一点。 互联网网页载有报告(因此本报告的载荷代码)。 在这一基类中,我们设定了所有可能的<代码>>>><>/代码>变量,这些变量据报是无效的。 与此类似:

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

然后,《基地报告》的定义如下:

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);
        }
    }
}

这样,你就确保任何用户在任何特定时间都记忆犹新。

如果记忆是令人关切的问题,即使采取这种做法,也可将个人变值储存在<代码>>>Session &然后在<代码>Page_Init &上发布新报告;在将其分配到CrystalReportViewer.ReportSource之前重新注入所节约的价值。 但就我们的情况而言,有40个用户每天拿走50+不同的报告,这种存储方式( Object &随附的房屋保存),自3年前使用该应用程序以来,我们就没有遇到任何记忆问题。 我仍然建议进行适当的负荷测试和装备;在把这一解决办法推向生产之前进行监测,因为结果可能因具体执行而有所不同。

当我为“晶体”报告撰写时,“结构”中的参数编码就是这样:

--Date Range
(
(table.datetime >=  {?Start Date} )
and table.datetime <  {?End Date} )
)

--Location
( {?Facility} =  All  OR  {?Facility}  = table.location))

当然,你总是可以选择把参数简单地列入晶体。 这种做法效率不高,有时比较容易。

I had to use explicit ReportDocument type instead of ReportClass because that raised an invalid cast for some reason, but otherwise, works EXACTLY as advertised AFAICT. viz.

...
...
 if (Session["<some identifier>"] != null)
                {
                    switch (Session["<some identifier>"])
                    {
                        case ReportClass rc:
                            crystalReportViewer1.ReportSource = rc;
                            break;

                        case ReportDocument rd:
                            crystalReportViewer1.ReportSource = rd;
                            break;

                        default:
                            return;
                    }
                }