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

2

5

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.

Shadowgraph answered 16/4, 2013 at 17:58 Comment(2)
Perhaps you're experiencing this issue?Hughhughes
That is close and I thought that too. However I have ALSO agreed with you on that point and this continues after a delete of the report, rebuild, redeploy. In fact in my issue I created three reports, an original, a copy of just copying the report and pasting it under 'Reports', and creating a brand new one from scratch. In all instances they would update the parameters and their default values as applicable. However if there was any reference anywhere to the shared dataset it would break. This is very strange that this would happen to new reports.Shadowgraph
S
1

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.

Shadowgraph answered 19/4, 2013 at 23:20 Comment(0)
S
6

I know this is an old question, but I just ran across this and was able to resolve my issue. Thought an updated option is warranted for others struggling with it. My issue had to do with the parameter settings on the Shared Dataset properties. The menu looks like this:

enter image description here

Specifically, make sure that you check the "Allows null value" option where needed. This instantly resolved my issue where a dataset would not work when pointing to a shared but embedding the dataset did.

Saleable answered 15/12, 2016 at 16:14 Comment(0)
S
1

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.

Shadowgraph answered 19/4, 2013 at 23:20 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.