SQL Server Reporting -10 minutes of inactivity cause loadsnapshot error

Hi all,

I have a front end application where I'm using the reportviewer control.

If the user open a report and don't do anything for 10 to 15minutes, and

then try to export the report in PDF, an error is raised:

Execution 'mlgd4355vz5mgouvwv2guz45' cannot be found (rsExecutionNotFound)

on the RS side the log says:

w3wp!session!1!02/27/2007-15:27:30:: i INFO: LoadSnapshot: Item with

session: mlgd4355vz5mgouvwv2guz45, reportPath: , userName: domain\username

not found in the database

w3wp!library!1!02/27/2007-15:27:30:: e ERROR: Throwing

Microsoft.ReportingServices.Diagnostics.Utilities.ExecutionNotFoundException:

Execution 'mlgd4355vz5mgouvwv2guz45' cannot be found, ;

Info:

Microsoft.ReportingServices.Diagnostics.Utilities.ExecutionNotFoundException:

Execution 'mlgd4355vz5mgouvwv2guz45' cannot be found

I have raised the timeout of everything to 2hours (session timeout, RS

timeout etc...) but there is no changes.

I have also used the local folder to store the temporary files instead of

the database, but it’s the same result.

There have been MANY posts on several forums however I haven't seen an answer to this to date.

Any suggestions would be welcome.

Our situation is very similar to yours. We use a WCF service to wrap a call to an instance of a ReportExecution2005 ReportExecutionService in order to print a report. This would be working fine until around the 10 minute mark, when the LoadSnapshot error would occur. We, too, tried setting a variety of configuration keys in the hope this would affect the apparent timeout. After long investigation, we discovered that the problem was down to caching.

The first time we attempted to print a particular report, the following code would be run to set up the report parameters:

private static ReportExecution2005.ParameterValue[] LoadReport(string report)
{
    // Attempt to load the report based on the current authentication settings
    ExecutionInfo executionInfo = ExecutionService.LoadReport(report, null);
    // Create an array to store the parameter values
    ReportExecution2005.ParameterValue[] parameterValues = new ReportExecution2005.ParameterValue[executionInfo.Parameters.GetUpperBound(0) + 1];
    // Iterate the parameters this report expects and set the names in the parameter values array to match
    // The actual values in the array are set later
    int arrayIndex = 0;
    foreach (ReportExecution2005.ReportParameter parameter in executionInfo.Parameters)
    {
        parameterValues[arrayIndex] = new ReportExecution2005.ParameterValue();
        parameterValues[arrayIndex].Label = parameter.Name;
        parameterValues[arrayIndex].Name = parameter.Name;
        arrayIndex++;
    }
    return parameterValues;
}

Those parameters would then be stashed in a Dictionary object, with the particular report (the report input parameter above) as the key and the parameters (returned by the LoadReport method above) as the value. We did this in an attempt to save having to create parameters each time we wanted to print a report. However, a bright spark of a colleague pointed out that WCF services are stateless and you should not attempt to perform caching within them.

I removed the Dictionary nonsense and simply let each request to print call the above LoadReport method - and it works! Finally this has brought to an end several days of anguish! As you say, it appears a lot of other people have been experiencing the same issue. I hope this solution points you in the right direction.

1 Reply

Know the answer? Post it — somebody with the same question will find it here.

Mario17y ago
Our situation is very similar to yours. We use a WCF service to wrap a call to an instance of a ReportExecution2005 ReportExecutionService in order to print a report. This would be working fine until around the 10 minute mark, when the LoadSnapshot error would occur. We, too, tried setting a variety of configuration keys in the hope this would affect the apparent timeout. After long investigation, we discovered that the problem was down to caching.

The first time we attempted to print a particular report, the following code would be run to set up the report parameters:

private static ReportExecution2005.ParameterValue[] LoadReport(string report)
{
    // Attempt to load the report based on the current authentication settings
    ExecutionInfo executionInfo = ExecutionService.LoadReport(report, null);
    // Create an array to store the parameter values
    ReportExecution2005.ParameterValue[] parameterValues = new ReportExecution2005.ParameterValue[executionInfo.Parameters.GetUpperBound(0) + 1];
    // Iterate the parameters this report expects and set the names in the parameter values array to match
    // The actual values in the array are set later
    int arrayIndex = 0;
    foreach (ReportExecution2005.ReportParameter parameter in executionInfo.Parameters)
    {
        parameterValues[arrayIndex] = new ReportExecution2005.ParameterValue();
        parameterValues[arrayIndex].Label = parameter.Name;
        parameterValues[arrayIndex].Name = parameter.Name;
        arrayIndex++;
    }
    return parameterValues;
}

Those parameters would then be stashed in a Dictionary object, with the particular report (the report input parameter above) as the key and the parameters (returned by the LoadReport method above) as the value. We did this in an attempt to save having to create parameters each time we wanted to print a report. However, a bright spark of a colleague pointed out that WCF services are stateless and you should not attempt to perform caching within them.

I removed the Dictionary nonsense and simply let each request to print call the above LoadReport method - and it works! Finally this has brought to an end several days of anguish! As you say, it appears a lot of other people have been experiencing the same issue. I hope this solution points you in the right direction.
0