The links in the question and comments sometimes refer to non-SSRS reports: the syntax [subreport].[Report]![MyFieldName]
or [Reports]![YourReportName]![YourSubReportName]![TheValueFromTheSubReportYouWantToReference]
are not used in SSRS. It is, however, used in designing MS Access reports, as ojeffrey points out in the discussion you link to.
There is no common method to access data in a subreport. The SSRS model is that parent report data is processed, subreport data is processed, the subreports are rendered, results go back to the parent, then parent is rendered, including the subreport as appropriate. The only data passed between the two is parameters are passed into the the subreport, and rendered output is passed back to the parent. You'll see the that data passed in from the parent must be as report parameters here: http://technet.microsoft.com/en-us/library/ms160348(v=sql.100).aspx
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.
For citing authoritative sources:
This discussion sums it up:
No, referring to a report item in a subreport is not allowed.
But that is a bit old, there is also this more recent discussion of work-arounds, provided by Microsoft employee and a MS BI MVP:
You are going to need to replace the subreport item with a data region
like list, table, or matrix to be able to get the proper reference you
are looking for.
[Skipping down to another post]...
Now, it seems you want to calculate the
difference between main report and the subreport. Also, because they
have the different data source, so you cannot use nest
table/matrix/list, right? If so, one workaround I can think of is
pass parameter to the sub report and calculate the total/subtotal in
sub report. I mean, create several hidden/ internal parameters, pass
the values from main report to sub report through parameters and then
calculate the total/subtotal there.
Jeroen's answer to the linked question point towards the direction I would go: use a "Shared Dataset" and enable caching if the dataset is slow to execute. The same dataset execution can then be used for the parent and subreports. This can change the use of parameters: they usually get moved from the SQL query to the filter of the Dataset in the report.
But with the Lookup
function introduced in SSRS 2008R2, you can get very flexible with report level joins between datasets.
The details of how I'd design this depend a lot on how much other data needs to get passed back and forth, and how neatly the queries for the reports can be knit together.