deploymentreporting-servicesshared-data

SSRS Error: "One or more parameters required to run the report have not been specified. (rsParametersNotSpecified)"


Okay there are similar questions to this but this is NOT a duplicate. This error seems to come up when you have parameters referencing a dataset which is shared. Deleting the report from the server and redeploying does not fix in my case.

So I am developing on VS 2010 Professional with Business Intelligence Development Studio, BIDS, which is under source control with Team Foundation Server. I am deploying to a 2008R2 server which I thought may be the issue. The workaround is to change the dataset references to be embedded instead which stops this error dead in it's tracks but that is pretty poor in my opinion and I would like to have this work with shared datasets ultimately.

Things I have tried:

  1. Ensure the naming of the dataset matches the reference. EG: "Name is ClientQuery, shared dataset is ClientQuery"
  2. Ensure the naming on the server matches the refernces in step 1.
  3. Ensure that this is what is breaking it by removing the reference to the shared dataset, works right away then.
  4. Ensures that the shared dataset is not enabling some type of caching on the server.
  5. I had a filter on a second shared dataset limiting scope, I removed that and there was still an error.
  6. Removed all parameters and only added a single shared dataset, it gives error right away.
  7. Added an option to the parameters binding to say: "Allow Empty values". Did this with Nulls as well.
  8. Recreated EVERYTHING, a whole brand new RDL file, and copy and pasted only elements on the body of the report but explicitly created the parameters and the datasets and this STILL HAPPENED.

9. UPDATED - I have done the old destroy the RDL and then hope to redeploy. I found that a lot online. That does not work in this case. It is almost like this reference in the RDL:

    < DataSet Name="**ClientQuery**">
      < SharedDataSet>
        < SharedDataSetReference>**ClientQuery**</SharedDataSetReference>
      < /SharedDataSet>
      < Fields>
        < Field Name="CUSTOMER_ID">
          < DataField>CUSTOMER_ID</DataField>
          < rd:TypeName>System.String</rd:TypeName>
        < /Field>
        < Field Name="CUSTOMER_NAME">
          < DataField>CUSTOMER_NAME</DataField>
          < rd:TypeName>System.String</rd:TypeName>
        < /Field>
      < /Fields>
    < /DataSet>

It appears that somehow the mention of this refernce causes havoc. I would examine my bin(environment) directory under my project. (I deploy for multiple environments and set up QA, UAT, PROD, etc.. under solution config) Each time the RDL is getting updated as it should and posting the updates I am showing. I think 'rebuild' is a lot of the issue at times when people see their report files not updating on a server, in my case a rebuild usually gets updates to the RDL versus just hitting deploy first.

While all of this is happening the hard part is that it works throughout changes every time on BIDS seamlessly. So the error is dealing completely with what the source server believes the rdl data to represent.

Any help is much appreciated, I would rate myself advanced at SSRS but this one has me stumped of what the error is refernecing that it is not getting.


Solution

  • Okay so the answer Jeroen proposed and others is half right. My issue was that my source code was under an older SVN Source Control, that was deployed to an SSRS 2008 Server, then we migrated the code base to TFS Source Control. The issue appears to be that the Shared Datasets were BELIEVING to be different identifiers than they actually were. The simple work around IN ADDITION to deleting the files is to redeploy the shared datasets as well. In my case I went into my project settings and deployed them to a different location entirely under the report structure to keep them in the same area so: Reports/Datasets instead of just Datasets. This seems to clear up the issue in my case so I believe this was just a perfect storm. In doubt with SSRS just delete everything and start from the ground up I guess.