February 28, 2012 at 1:20 pm
How does one interpret an error message which says
The subreport 'Subreport2' could not be found at the specified location /xxxx. Please verify that the subreport has been published and that the name is correct.
even though the report has been published and the name is exactly the name spelled out as xxxx?
Is the error message itself one of microsoft's bugs where the error message has nothing at all to do with what the error is? Could it actually mean something is messed up in my attempt to link parameters between the main report and the subreport?
February 28, 2012 at 3:29 pm
How does one interpret an error message which says
The subreport 'Subreport2' could not be found at the specified location /xxxx. Please verify that the subreport has been published and that the name is correct.
even though the report has been published and the name is exactly the name spelled out as xxxx?
Is the error message itself one of microsoft's bugs where the error message has nothing at all to do with what the error is? Could it actually mean something is messed up in my attempt to link parameters between the main report and the subreport?
I had a similar issue when deploying to SharePoint. I had a report folder and a subreport folder, and my report was set to point to exactly where it needed to. When running the report, I would get an error similar (cannot recall exact message).
My subreports had to be in the same folder/location as the main report, for SharePoint, in order for the subreports to work.
Other than that, if stored on a local drive or share drive, make sure that you are using the full filepath name and not a mapped network drive location.
e.g.: "R:\\mynetworkhome\personal\" on your local machine should actual read the full path like "\\corpdomain\users\user1\personal\"
Hope this helps.
February 28, 2012 at 3:34 pm
Thank you, fellow grasshopper.
I did not specify ... both my main report and the selected subreport are in the same folder, and I am running locally on my laptop rather than on the server.
(According to the few pages I found about this on the Web, "publishing" is not an issue since I'm running locally. That's why I mention it.)
March 6, 2012 at 8:59 am
It turns out that the error message SSRS was throwing had NOTHING at all to do with what the actual error was. Not knowing any correct way of handling parameters to a subreport I had changed the names of the parameters in the subreport. But I had not changed their respective references in the subreport's queries. So the queries in the subreport were referencing parameters which did not exist. When I corrected that error and ran again SSRS stopped lying about not being able to locate the subreport.
However later on in development SSRS repeated the same lie claiming he couldn't find the subreport but this time I couldn't discover any error on my part. So I gave up and started over from scratch. And now my subreports are receiving the parameter values AND working pretty well.
So I guess the moral of this story is Don't trust SSRS error messages to be meaningful.
April 12, 2012 at 12:32 pm
I had the EXACT same problem. I've got a main report off of a SQL server, and a subreport off of an Oracle server. After finally finding that SSRS needs a colon symbol instead of an @ symbol to paramaterize a value, I kept trying to preview the report with the error that I hadn't published, even though I was running locally.
I just refreshed after making sure my subreport's parameter properties were actually referencing a field in my main report's dataset. Then wham-bam-thankyou-ma'am it worked.
Moral of the story is the same: don't necessarily trust the build error list in SSRS, because it's tricksy!
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply