SSRS Report Name case driven from URL

Reading Time: 2 minutes

UPDATE: This issue still exists in SQL Server 2016.

This is more of a formatting bug (read: undocumented feature) that I discovered in SSRS 2014 that no doubt exists in all previous iterations.

It was initially discovered in SharePoint integrated mode when using Powershell to find/replace SSRS report URLs (though it is present in native mode too as demonstrated below). I had to switch the URL case to lower in order to accurately match my search term. The script then saved all these report URLs in lowercase. At which point we discovered that report names were all presenting on lowercase.

To cut to the chase, it looks like the SSRS ReportName built-in field (Globals!ReportName) is directly affected by the URL’s case. Thats not all, the URL’s case is affecting the breadcrumb and all other use of the report name in the report’s properties pages!

IE. http://server/reports/Pages/Report.aspx?ItemPath=%2fExample+Report+Name&SelectedSubTabId=GenericPropertiesTab

This example wields a standard looking report output with the same syntax in the breadcrumb & as you’d expect, the properties page too. Excellent!


Now, if we alter the report name’s case within the URL, adding random capitalized letters for example we can see how that exact format affects the report below (You would assume the properties page would be fed from the Catalog table within the ReportServer database regardless of the URL syntax. Apparently not!)

ie. http://server/reports/Pages/Report.aspx?ItemPath=%2fExample+rEpOrT+nAmE&SelectedSubTabId=GenericPropertiesTab


As mentioned above, this is also evident on the properties page.



Moving back to the parent folder and reloading the report returns the case to normal though, implying it is in fact stored correctly in the database Catalog table but ultimately the URL has final say on syntax.

I havent found any acknowledgement for this issue let alone a workaround but Ill edit & update if I find anything.

You may also like...

1 Response

  1. 26th July 2016

    […] PS. As updated¬†in this previous post, this issue/quirk still applies in 2016!¬† […]

Leave a Reply