none
Default value or value provided for the report parameter is not a valid value when running a report execution triggered data driven subscription

    Question

  • Am receiving the error message "Default value or value provided for the report parameter is not a valid value" when attempting to save a data driven subscription when 
    choosing to make the reports parameter based on a field returned by the recipient list query for the subscription.

    If I choose the option "Specify a static value" the subscription saves fine. I then test it by forcing a report execution snaphot to be generated and the emails are sent out. Unfortunately, the reports are all the same as the parameter is static!

    The parameter in question is string and allows nulls and blanks. It used to have a query based list of values, but I got rid of that thinking that was a problem. So now I have a string parameter which technically should accept anything yet I get the error whenever I try and make the subscription substitute the parameter with values from the query.

    I already checked the recipient list query and it returns all valid strings.
    Tuesday, June 16, 2009 1:30 AM

All replies

  • Hi Meumax - I was able to repro the scenario you describe (except I got it when the subscription fired, not when saving the subscription) and will enter a bug, but I expect it will be a design change to not allow specifying parameter values for DDS's triggered by execution snapshots.

    The reason is that only "report execution snapshots" can be used to trigger subscriptions, and since they only work with reports that have default parameters, there can only be one set of parameters that will match the cached version of the report when your subscription uses it. If you tried to use a DDS query to provide multiple parameter combinations, they would not be able to match the version of the report that was cached with a single set of parameters.

    You can use a DDS to specify the email settings in the subscription if you want to send the reports to multiple recipients, but they will get the same version of the report given the parameter values provided by the default.

    I've not yet had a chance to discuss with my peers, I'll update the thread once we've had a change to review and investigate.

    Thanks, Dean
    Wednesday, June 17, 2009 1:39 AM
    Answerer
  • Hi,

     

    If you were to select a report snapshot for the subscription, you wouldn’t be able to edit parameter values used as query parameters. The values in the rendered report for the subscription will match those of the snapshot. However, if the report parameter is used as a filter, you can modify the parameter in a subscription. I mean, filter the data with parameter in a filter of dataset not in the query string.

     

    To sum up: The subscription does not base on snapshot, you don’t need to set the default parameter and the users can select the parameter at will after clicking the link to refer to the report server. And if you design the parameter with the option “allow blank” in report design, you even don’t need to specify the parameter when you set the subscription before sending, the users will received a blank report. Or if the query string looks like this:

     

    Select * from table where @parameter =*** or @ parameter is null

     

    The users will receive all the data in e-mail.

     

    If the subscription does base on snapshot, you need to filter the data with parameter in a filter not in the query string, after that the user also can select the parameter at will. Otherwise, you have to set the default parameter value and the users cannot change the parameter value after switch to the report server.

     

    For more information, see:

    http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/5deb9a1a-3f85-47c9-af32-0ab3018b51f2

     

    Hope this helps.

    Raymond

    Wednesday, June 17, 2009 8:15 AM
    Moderator
  • Hi Meumax,

    If the options suggested by others do not work for you, check this thread http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/5d3e0c71-b1e8-45ff-acbf-5a4797710e89/ who reported a similar issue.
    I also would encourage to file a bug for this through http://connect.microsoft.com if this is not fixed.
    Thanks

    Wednesday, June 17, 2009 1:49 PM
    Moderator