one parameter doesnt get passed to subreport from parent

Question

Hi we run 2014 enterprise. I'm noticing in one sub report that the city parameter doesn't get passed from the parent report (B). That parameter allows multiple values in both the parent and sub report. The other 4 parameters get passed with no problem but only allow one value per. And the troublesome parameter can get available values from a data source query in the parent and sub when those reports are run stand alone.

the parent's parent (A) has the same setup and it has no problem passing the city parameter to B.

Even that familiar behavior where the parameter section on any sub report shows as being collapsed when it is rendered, doesn't occur on my sub report because ssrs is clearly expecting cities to be entered in the sub report.

I'm stumped.

Answer 1

Hi @db042190 ,
I understand that you have three reports, named A, B, and C. Where B is the sub-report of A, and C is the sub-report of B. Your current situation is that the parameters cannot be passed from B to C, but the parameters can be passed from A to B correctly.
I tested it locally and the above situation did not occur. I guess there may be a problem with the parameters of your C report.

In Report Builder, if a parameter is missing from the Parameters list and the subreport has a default value defined, the subreport will be processed correctly.

In Report Designer, all parameters that are required by the subreport must be included in the Parameters list. If a required parameter is missing, the subreport is not displayed correctly in the main report.
Best Regards,
Joy

---

If the answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

well this is bizarre. yes joy , tfs/vs will update(grade) the rdl in vs2017 if you change something, not if all you do is open it. maybe thats just in our installation because i believe at most places i've been opening checks it out also, but not always here.

so i changed a param prompt, saved, and then saved again. vs2017 changed the stamp inside the xml to 2016 in tfs.

i deleted the sub report on the server and redeployed from vs/tfs. it continues to be broken. i downloaded its new xml and one of its parent's xml and see a stamp of 2010 (not 2016 like it shows in tfs) as you see below. so something is still wrong. at some number of cities > 10 and aprox 392, this plumbing breaks down. to make sure the same report was executing i deleted the sub report again from the server, changed a param promt to have multiple colons, redeployed, recreated and yes the multiple colons show ij the param area,

xmlns="http://schemas.microsoft.com/sqlserver/reporting/2010/01/reportdefinition"

Answer 3

hi this isn't an answer but possibly the beginning of one. I noticed this by accident working on something else.

the parent and grand parent reports have a city drop down of 390 city candidates. the sub report had a dataset that drops down 391. The extra city is a special accounting case where the code and value aren't really a city but rather a placeholder for a certain fact that cannot be associated with a city. and that city is irrelevant to the parent and grand parent reports.

so i doubt that the fact the subreport uses a different proc for the dropdown is really the "answer" but that the datasets are different and ssrs tries to be smart in a dumb, non business way. I think ssrs is comparing what is passed after sorting on keys and throws the passed dataset away when a key would show in the sub's full dataset that isnt in the passed dataset. it seems ssrs knows when a "select all" was chosen in the parent and grandparent param. But i'm just guessing.

i dont usually have time )this is an older version of sql) or motivation (we're always told "that's by design") to invest in MS's bugs, but i tried a low cost experiment and temporarily substituted the same city dataset proc in the sub report and all 390 cities were passed. This is an older version of sql so we may find its fixed in the version we will be upgrading to.