There are 7 built in options for exporting SSRS 2008 reports.
I was wondering if there is an easier way to code the following in SSRS when chosing the export option:
=IIF(Globals!RenderFormat.Name="WORD" OR Globals!RenderFormat.Name="XML" OR
Globals!RenderFormat.Name="CSV" OR Globals!RenderFormat.Name="TIFF" OR
Globals!RenderFormat.Name="PDF", Globals!RenderFormat.Name="MHTML" OR
Globals!RenderFormat.Name="EXCEL",true,false)
Is there a way to write the code above without having to list each export option listed? A way that includes all the export options? If so, how would you write that code?
The suggestion from ShellNinja won't work as a visibility expression because of the order in which expressions and other report items are processed and rendered.
The article Built-in Globals and Users References on TechNet hints at this (allbeit a very vague hint) under the RenderFormat subheading where it says that:
Globals!RenderFormat.Name is available during specific parts of the report processing/rendering cycle.
Globals!RenderFormat.Name is not populated prior to expressions being evaluated, it's populated on completion of the current render request which is why it can't be used in a visibility expression but will display the name in a textbox.
Globals!RenderFormat.IsInteractive is populated prior to expression evaluation and is the only way of hiding/showing a report item prior to a report being rendered. RPL and HTML are considered fully interactive formats, all other formats are not or only support some interactive features. More information on this can be found in the article Comparing Interactive Functionality for Different Report Rendering Extensions on TechNet.
Use "RPL" for a simpler IIF expression so that any other format is "EXCEL", "CSV", "WORD", etc. When the report is displayed in the report server viewer or a ReportViewer control the RenderFormat is "RPL".
=IIF(Globals!RenderFormat.Name = "RPL", true, false)
The above code when set as a visibility expression will show the field when rendered in SSRS and hide it on export.
Tip: When you have a long IIF expression use a switch expression Reporting Services Expression Examples they are by far cleaner and easier to manage.
The expression below, placed in the Column Visibility dialog box for a selected column, displays the column only when the report is exported to Excel; otherwise, the column is hidden.
=IIF(Globals!RenderFormat.Name = "EXCELOPENXML" OR Globals!RenderFormat.Name = "EXCEL", false, true)
This is mentioned in the MSDN itself. Hence it does work!
Related
I originally thought this would be an easy task, but after several hours of research I'm reading there may be a SSRS bug when exporting hidden fields to CSV which doesn't make this possible?
What I'm looking to do:
I have a report with several columns (let's say 50). I have a parameter drop down for REPORT_VERSION that allows the user to select "Standard" (all 50 columns) or "Express" (only 10 columns). I've been able to display the 2 versions correctly, but when I export (the express version) to CSV it shows all of the columns (and or tablixs) and not what the results look like.
I've read about and tried:
If I create 2 tablix and hide one based on the parameter value, the export to CSV still shows both the visible and hidden tablix.
If I use =IIF(Globals!RenderFormat.Name="CSV", True, False) - this doesn't work for CSV output
Changing DataElementOutput = NoOutput. This hides the columns or table from the CSV output, but this can't be dynamically changed based on a parameter value.
Could this be done in the "custom code" section via vbscript??
Many of the articles and threads I read through dated back to 2010-2012 so hopefully there is a solution now? I'm really at a less here.
Help would be greatly appreciated. Thank you
I was able to get this to work in SSRS 2008 and 2012 based on your attempt #2. I created a dummy report with a data source query of
SELECT 'value1' as col1, 'value2' as col2
I then added the following expression to Column Visibility to column2
=IIF(Globals!RenderFormat.Name="CSV", False, True)
Note that the true and false are reversed from your sample. When the report was generated, column 2 was hidden, but when exported to CSV, column 2 was present.
To incorporate your parameter into the visibility expression, you could do something like this
=Switch(
Globals!RenderFormat.Name="CSV", False,
Parameters!REPORT_VERSION.Value = "Standard", False,
True, True
)
This will set the hidden property of the column to false if rendered as a CSV, or if "REPORT_VERSION" parameter is set to "Standard", else hide the column. This expression would need to be added to the Column Visibility of every column you want to hide in the "Express" version of the report.
EDIT
OK, I understand the issue now and can replicate it (I was backwards on the concept). You can explicitly set the visibly of a column to hidden and it won't show up in a CSV export. However, when you attempt to control this via an expression, the CSV export ignores this setting.
Data based exports look to be controlled by the "DataElementOutput" property. Setting this to "NoOutput" will suppress this that element from the CSV output. Unfortunately, it doesn't appear it can be controlled by an expression. Microsoft does not appear to have any plans to change this(https://connect.microsoft.com/SQLServer/feedback/details/431073/ssrs-programatically-controlling-the-dataelementoutput-property)
The Microsoft connect request hints at creating two tablixes and filtering out all the results for each one based on the parameter supplied (i.e. "Express" or "Standard"), additionally hiding the other tablix based on the parameter value. I tried this and it worked halfway. Although the other tablix had no results, it would still export the column headers and one blank row.
Now I'd be curious to know what a good solution would be to this issue.
We are in the process of updating from the SSRS package in SQL 2005 to SQL 2012. SSRS seems to work fine, even with the original report model, but none of the reports we create have clickthrough functionality. Even if the entities are linked in the report model, the table simply doesn't have any clickthrough links. The older reports carried over from the SQL 2005 SSRS do still have the functionality however.
We are using the enterprise version of SQL, which claims to have the feature. Is there a manner in which I need to turn it on?
Clickthrough doesn't only matter on the underlying reporting server's capability which supplies the data, but also if the report designer application (in our case Report Builder 3.0) support it too.
#djangojazz is using SSDS (successor of BIDS) in his solution, and it also requires cubes. I think #ChargerIIC wanted to use Report Builder. It seems that Report Builder 3.0 is not a successor of Report Builder 1.0 in all respects. Particularly this clickthrough feature may be a difference.
See Report Builder 3.0 FAQ: http://download.microsoft.com/download/7/F/D/7FDAA75C-1273-4DFE-8EC6-D9699C3EE47F/SQL_Server_2008_R2_Report_Builder_3_0FAQs.docx
See the question: "What are the key differences between Report Builder 1.0 and Report Builder 3.0?". The last row in the answer table is crossed out, but it says that 1.0 support infinite click through, while 3.0 is manual.
"Q. Is this a replacement for Report Builder 1.0?
A. Not for this release. It does replace Report Builder 2.0 but there is still some additional functionality from Report Builder 1.0 that did not make it into this release that has been prioritized for a future release."
To set up a drill through report for a master report you must have two reports. For the sake of simplicity I will keep my example super simple. Let's start with the drill through report as that is the lowest level. For both examples assumple you are using a Shared Data Source you make up. This is written with instructions for 2012 Business Intelligence Development Studio assuming you are in a Report Solution for SSRS and a working SSRS Project. You get to this with All Programs > Microsoft SQL Server 2012 > SQL Server Data Tools (Once you open it, it will be called Business Intelligence).
Create a new 'Item' for a blank report and call it 'SubReport'
Open up 'Report Data' and add your Shared Data Source
Right Click 'Parameters' and 'Add Parameter'. Add a simple text parameter and call it 'Prompt'.
Open the 'Toolbox' and drag a text box onto the surface.
Type in 'Hello from [#Prompt]'. You can test the report in 'Preview' mode and see that you can pass whatever text string you want to it to get a value.
Now for the master report, repeat steps 1 and 2 but call the report 'MasterReport'
Add a 'DataSet' by right clicking the 'DataSource' you just created and click 'Add DataSet'. For example I will just create a super simple set I call 'People'
DECLARE #Person TABLE (person varchar(8)); INSERT INTO #Person
VALUES ('Brett'), ('Sean'), ('Chad'), ('Michael');
SELECT TOP 100 *
FROM #Person p
Now go to the 'Toolbox' and drag and drop a 'Table' element onto the report.
Click on the most left 'Data' cell of the 'Table' you just dropped and hover over it and select the little box that appears in the upper right and you should see a column named 'person' that matches my dataset above. Select that and the cell and header will now be populated.
Now for the real magic to actually happen.
A. Right click the cell you just created and 'Text Box Properties'.
B. Select 'Action' on the left pane.
C. Choose the radio button 'Go to Report'. (More options now appear)
D. Under 'Specify a report:' select the dropdown for the value 'SubReport'
E. Under 'Use these parameters to run the report:' click 'Add'
F. Under 'Name' you will see the parameter name 'Prompt' from the report we created in step 3
G. Under 'Value' select '[person]' which is from the dataset we created in this report in step 7.
Preview the report and now when you 'hover over' values in the table a pointer appears. When you click on a cell you DRILL THROUGH to the other report in a new screen.
I hope this helps, the important thing to keep in mind is that you can isolate your logic to seperate the two reports as distinct entitites that are loosely coupled by passing values from one to the other. You can make the parameters hidden, make more of them, you can nest the report inside of your cell if you like, etc.
I am using SSRS 2012, and Excel 2010, I want to hide a column when Exporting to Excel, after looking through some of the forums it seems the best way to do this is by going to the Column or Text box of what you are looking to hide and under the Visibility/Hidden option set the Expression to be :
=IIF(Globals!RenderFormat.Name = "EXCEL",true,false)
I have tried this and for some reason it doesn't work, however if I reverse the options of true and false I can get it to hide the column in SSRS but it also hides this in Excel. Could this be an issue because of the version of Excel I am using?
In SSRS 2012 the XLSX export format was introduced, which uses a different renderer than XLS exports.
So I wonder if this is causing the issue. Modify the visibility statement to consider both export formats, something like:
=IIF(Globals!RenderFormat.Name = "EXCEL" or Globals!RenderFormat.Name = "EXCELOPENXML"
,true
,false)
This seems like a good first test.
Because you are returning a boolean you do not need the IIF:
=Globals!RenderFormat.Name = "EXCEL" or Globals!RenderFormat.Name = "EXCELOPENXML"
or this is also valid:
=InStr(Globals!RenderFormat.Name,"EXCEL") > 0
I'm using now SQL Server 2008 R2.
My website shows the report exactly as it is, including the container where the parameters appear (the client prefers it that way).
However, my website solution includes localization (Portuguese, English, Spanish).
I've tried to translate the parameters by creating one parameter for each language, and then show them according the selected one. It didn't work in SSRS 2008. Because I don't know how to find the visibility properties of prompt.
Does anyone know a solution... Or if SQL Server 2012 has solutions for translating parameter's prompt, or conditional visibility?
Thanks.
The only solution I've found so far (SSRS 2008, 2008R2, 2010, 2012) is to break the DRY commandments, and duplicate the reports with language codes as part of the report name (e.g. MyReport_sp.rdl, MyReport_de.rdl, etc) and then place a web service between the client request and the SSRS instance. The web service then has to field the request to the correct report based on a "Culture" parameter passed with the client's request.
This is NOT a good solution, though at least the Culture param is used in localizing the rest of the report as well. We still have hopes that at some future date MS will add prompt localizability and we can rename the report to MyReport.rdl and just have everything actually localized. Hmm, what a concept...
Another workaround would be to just put a number in the prompt for the parameter then prefix the label of each parameter with the localised version by either using "get values from query" or by using the expression builder with a switch statement in the label expression.
For the get values from query option you would have a dataset something like this if you have the translated versions in the query:
SELECT ParamLabel, ParamValue
FROM MyLocalisedParameters
WHERE UserLanguage = #Language
Or like this if not:
SELECT
CASE #Language
WHEN 'pt-PT' THEN 'Selecione Departamento: ' + ParamLabel
WHEN 'es-ES' THEN 'Seleccionar Departamento: ' + ParamLabel
ELSE 'Select Department: ' + ParamLabel
END AS ParamLabel
, ParamValue
FROM MyParametersTable
in both cases creating and assigning the Globals!Language to a Parameter called #Language.
Or if using the expression builder for a hardcoded set of values it would look something like this:
either way the end result would look something like this:
Not perfect but functioning and easier to maintain than several copies of the same report.
If you want it to look a bit tidier then just have the Parameter prompt as only one entry in the parameters list and set it to the default value to avoid repetition on every line.
There is none...
As per connect.microsoft.com, this feature has been requested after SSRS 2005 has been released, and while it is on Microsoft's TODO list, the programmer time to do this has never been allocated, and hence in 2012, SSRS is still not capable of doing that.
Although it's (with much effort) possible to translate everything else, it's not possible to translate the parameter prompt.
There is NO conditional visibility either, visibility of parameters is fixed.
Also, there is no way having SSRS use a supplied language instead of the one set in the browser language settings.
The only thing that you CAN do is write a C# program that loads your XML file, get's the report's parameter name(s) (and possibly the report's name as well), looks them up in a database, and automagically creates N reports for n languages.
Then, you have to redirect your users to the report in their language.
You then only need to write an upload tool, because you won't want to do that by hand.
The other way is to use the ReportViewer control, and re-implement parameter selection.
I think there's CrissCross that tries to do that, but it failed in all but 2 of the reports that I tested.
An evil hack would be:
parametername: babla_language1 / blabla_language2 / blabla_language3 / blabla_language4
and then use jQuery to get that string. do string.split('/')[index_of_language]
and then prey that / is never within "blabla_languageXY"
Edit:
I actually did that. You have to use setInterval to do it, because there is no way to detect change when you select a parameter.
How can I use checkbox as a parameter in SSRS report? There in no built in control for that.
If you must have a check box you can't use the built-in SSRS interface for collecting parameters. Microsoft Connect has an issue regarding this.
You will need to make your own UI to collect the parameters and then eitehr redirect the user or return the report to them. Depending on your requirements, the simplest ways may be using SSRS with URL Access or using the reportviewer webpart.
If you need to implementing checkboxes on top of your report, you can use a multivalue text parameter. You can enter the default data manually and then it shows a combobox with the checkboxes you want. Each checkbox can be accessed using the same parameter name and an index. For example if the following condition is True then it means sombody has selected a checkbox that its value is 'value1':
InStr(Join(Parameters!p_myMultipleValueParameter.Value,","), "value1")>0
Note: In this case beware of text similarities. In same cases a string value of a checkbox may also be a substring of another value like 'no1' and 'no12'
While you can cannot do native checkboxes, you can do Radio buttons via Datatype Boolean.