SSRS – Adding Date to Exported Filenames

When you export a report from SSRS (to PDF or Excel, for example) the filename defaults to the name of your report. But recently, one of our clients wanted to have the current system date automatically added to the report name. For example, if the report is called “Task List” and it was run on January 1, the client wanted the file saved as “Task List 2013_01_01.” (Yes, you can do this manually but generating it automatically makes it more user proof.)

Unfortunately, there’s no easy way to do this. As a Microsoft SSRS Consultant, we did come up a few methods, two of which we’ll describe below. Please note: These solutions are NOT supported by Microsoft – if your team is caught, the Secretary will disavow all knowledge of your actions. (We’re joking, of course.)

SSRS stores its metadata in a SQL Server database called ReportServer. In that database the directory structure of the SSRS installation is stored in a table called Catalog. This table contains the root, the folders, all of the connection files, reports, etc.

Of interest here are the Path and Name columns. They are one part of the pathway that drives the default export filename. Conceivably, a SQL procedure could change these to meet your requirements and be scheduled to run on a regular basis.

However, because of the clunky nature of this method (exporting a report is client-side, so the solution should ideally be client-side as well) and its various side effects (this method would change the report name, not just the default export filename) we moved to the next method.

Like most web apps, SSRS executes the ECMAscript standard – aka Javascript – on the browser. By inspecting the web app that SSRS delivers, we tracked down the logic that exports reports. It’s a piece of SSRS called ReportViewer. However, SSRS delivers this piece to the browser indirectly, which makes it difficult to customize.

Along the way, we found that SSRS does serve at least one Javascript file directly: it’s called ReportingServices.js, a collection of odd helper functions such as PadIntWithZero() and confirmDelete(). This file is typically located in <SQL Server Folder> \Reporting Services\ReportManager\js, and that’s how we got into the fortress. By exploiting the flexibility of the Document Object Model, we could hook into the ReportViewer object by modifying the seemingly unrelated ReportingServices.js – as long as it was all part of SSRS.

The actual code customization was trivial. In fact, we found a user modification online for MS Dynamics CRM that essentially accomplishes the same goal. And since Dynamics CRM uses the ReportViewer module as well, we only had to adapt that code slightly to meet our needs.

The concept is simple: ReportViewer has a variable called ExportUrlBase, which stores the default export filename (among other things). So, all we had to do was modify ExportUrlBase and change the default filename.

In the above code, the try-catch block as well as the if(r == null) block are set up so that if the function is called before the ReportViewer module is fully loaded, it won’t modify ExportUrlBase, but will instead keep checking every second to see if ReportViewer has finished loading.

The else block runs once ReportViewer has finished loading. It was there we modified ReportUrlBase, finding FileName and tacking prefixFileName onto it. To save space, we added only a simple piece of text to the filename, but you could modify this to almost anything, including dates, server-processed data via AJAX, etc. The only drawback with this method is that when SSRS is updated, the Javascript mod will have to be reapplied.

So there you have it. This is the method we used to modify our default export filename, and it does the job well.