What's the best way to handle translations for stock text in a SSRS. For instance - if I have a report that shows a grid of contents what's the best way to have the correct translation for the header of that grid show up, assuming the culture of the report is set correctly.
Put another way - is it possible to do resources in a SSRS report, or am I stuck with storing all that text in the database and querying for it?
AS far as I know, there is no way to localize a report (meaning automating the translation of string litterals)...
Like you said,you basically have to use the User!Language global variable to catch the user's settings and then use that to retrieve the appropriate strings from the DB...
However, you can adapt the display of currency/numeric/date fields according to the user locale. Also possible is changing the interface of the Report Viewer to match your user's langage.
Here are a few links giving tips on how to adapt the locale:
http://www.ssw.com.au/Ssw/Standards/Rules/RulesToBetterSQLReportingServices.aspx#LanguageSetting
Langage pack for Report Viewer:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e3d3071b-d919-4ff9-9696-c11d312a36a0
Related
We are currently using a generic report which will be used differently by multiple usergroups. We have made this possible by creating linked reports with different settings of hidden parameters (such as 'show column x', 'enable feature y').
These settings (parameters) are needed on other reports as well, so we pass them along using the Go to ... Action.
To create the look and feel we are after, we are passing some additional parameters as well, HTML Viewer commands and Report Server commands such as &rc:Parameters=False (reference).
Unfortunately, this leaves us with only the option Go to URL, since Microsoft hasn't implemented these commands for Go to Report. This means we have to pass our settings (the hidden parameters) along in the URL. This results in a security issue, example given: &PARAMETER_ENABLE_FEATURE_Y=False.
The user might notice this parameter in the URL and is so given the possibility to enable this function by editing the URL to &PARAMETER_ENABLE_FEATURE_Y=True.
So my question is: how to use an Action in Reporting Services while preventing users from editing our sensitive parameters and while being able to use HTML Viewer commands and Report Server commands?
You will never get complete security in this sense if you absolutely have to use URL based parameters.
When navigating via the URL, the only way you can hide parameter values without hard coding them is to make them data driven. In your scenario however this will not be 100% secure as you will still need to pass the value that populates your data driven parameters.
This level of obfuscation is probably enough and can be achieved by collating a list of either every parameter combination or just the ones your need and assigning it an ID that you can call in a dataset. This can obviously still be changed by your users should they get curious and can be a faff to maintain.
I would say your only other option is to hide the URL bar completely by providing a 'landing page' for your reporting and displaying everything in an iframe. This frame can be targeted with a javascript link in your Go To URL:
="javascript:void(window.open('URL to open','iFrame Name'))"
If you are able to though, I would advise you group your users into Active Directory security groups and then maintain a collection of permissions and customisations per group. You can then check which groups a user is a part of using custom code similar to the answers here and return the required parameter values accordingly.
Doing things this way will also enable you to maintain which groups can see what from a central location, assuming you have rolled out the same parameter structure across all reports.
Does anyone know of a way to add an Excel icon somewhere more visible for the user to do an export without having to click on "Actions". Not sure if any of that is customizable?
Additionally, is there a way to create a drill-through report that renders in Excel. I was trying to figure out the RS:format stuff, but not sure how to use this.
I'm trying to make the report as user friendly as possible.
Thanks.
There certainly is, you can do an export using a URL as detailed in this MSDN article: https://msdn.microsoft.com/en-us/library/ms154040.aspx.
All you need to do is set that as the action of an image you place on the report, and you have an export icon. The general format is:
http://myrshost/ReportServer?/myreport&rs:Format=Excel
The main item to note is that myrshost/ReportServer is not going to be the same address as you use when browsing through reports. Instead, it's probably going to be SERVERNAME/ReportServer_INSTANCENAME, filling in the name of your server and database instance respectively.
Edit: A more concrete example of what this would look like:
http://sqlhost/ReportServer_Report2016?/Rentals/Balance%20Overview&rs:Format=Excel
Is it possible to add a report description (text) near the parameters area, before the report is run in the Report Builder 3.0. Essentially, when the users click the report and right before they run it, I want to provide them with a small description of what the report does and what the parameters. I can do that in the footer but it wont help, because the footer is only generated after the report has executed. Please let me know.
Thanks.
This is not possible with the default SSRS interface. You'll have to wrap SSRS with your own interface to add this.
To build your own SSRS interface, you can use a few different methods, such as embedding a ReportViewer control in a Asp.NET application, or using URL access in an iframe. See How to change the SSRS input parameters position in report
Of course, with Javascript and client side DOM manipulation, you probably could sneak your content into place, but it's not a supported option.
The main problem is that you can't show a report if parameters are needed for it until those parameters are chosen. If you don't want to provide default parameters another way to solve this problem is by actually having 2 reports.
In report #1 you put the parameters and the text box of instructions, but nothing actually using those parameters.
In report #2 you put the parameters and the actual report.
At the bottom of report #1 have a button, that just goes to report #2 passing the parameters selected.
I've used this technique to provide instructions on parameters when I want a quick-and-dirty solution (as opposed to a proper solution such as what Jamie suggested with embedding)
I've tried searching all over the internet for anything close to what I'm looking for and have been very unsuccessful. What I am wanting to do is to create a parameter in SSRS that shows the name of the report in the parameters section. But I want it to only be a label, instead of having a drop down box. I know if you take away the available values it makes it editable. If there is even a way to make a default value read only without having to have available values I think that would be okay as well. Any help would be greatly appreciated.
Parameters are not meant for this purpose. Even if you building the parameters with the RDlObjectModel the report parameter object doesn't even allow the parameter to be read only. I suggest to write your own custom interface to show headers and use a report viewer control.
So I have a report in Reporting Services 2005. In it is one parameter (ConnectionString) which determines which data source the report will use. It also has several other parameters which are dropdown lists derived from the data source chosen in the ConnectionString parameter.
In Report Manager, this works great. All of the dropdowns are greyed out at the beginning. When you choose your data source, the page requeries/repaints and all of the available parameter values for the other parameters are filled in based on the queries for those fields.
However ...
In the ReportViewer web control, when the report is first loaded up, instead of dropdown boxes all of the other parameter fields are just empty textboxes. Choosing a different data source for the ConnectionString parameter doesn't requery/repaint the other parameters.
I've been flipping through the ReportViewer programming reference to see if there's some way to replicate the Report Manager's way of reloading the webpage with the report viewer upon certain parameter changes, but I can't find anything there that isn't over my poor little .NET head.
Any ideas?
Not sure if this is any help but I do have a suggestion. I would try pulling the logic for dropdown boxes out of the report and put them in an ASP.net page. Then pass the parameters to the report and control the rendering/refreshing.
HTH
UPDATE: So it turns out you must provide a default value for any parameters which in turn affect other parameters in your report in order to get the dropdown box to load properly on initialization. Also note this is recursive - so if you have a parameter which affects another parameter which affects another parameter, both the first and second parameter must have default values.