I am working on a report which has many Expressions defined and would like to check all of these Expressions for the occurrence of some particular string - is this possible?
For example, I'd like to be able to identify all Expressions which contain the text Round( so that I can determine whether there's some unnecessary rounding being done.
If you don't want to do it fully automated, you can simply download your report file (.rdl) from the server and open it in a simple editor (the file is in an xml-based layout) and search for "Round(".
Related
I use the MS Access 2013 Expression Builder regularly.
But one thing I've never managed is simply to show only the first (say 25) characters of of a text field on the report.
It would seem to be a no-brainer. I've done far more complex things in Expression Builder without an issue. But shortening a text field on a report always return #Type! no matter how I try to adjust the expression.
It would seem to me that all I need is:
=Left([CompanyName],25)
But it just doesn't work! The report shows a #Type! error.
I can do this no problem by creating a RecordSet SQL string and setting the report RecordSource to it (with OpenArgs). But I can't manage it in Expression Builder.
What am I doing wrong?
When you build expressions for a form, then ANY column that exists in the datasource can be used - EVEN if not placed on the form.
However, reports have a significant difference. Your expressions ONLY work against data bound controls. In other words, the control has to be on the report (no doubt in this case in the details section of the report.
What this means is you have to drop into the details section (and you can and should use in design mode - add existing fields:
So, you need to add the Company name field to the report.
Of course you don't want it to display, so you can delete the label part, and set the control visible part = false. Eg: this:
Remember, you can't have the control reference its self.
In your case, the control you dropped "most" likely is called CompanyName, and then you changing the datasource expression to its self!!!
The other way?
well, you need to RE-NAME your control!!!
If you JUST drop the control onto the report, then its name will be CompanyName.
But, you NOW using =left(CompanyName,25) which POINTS to its self!!!!
So, as noted, you can drop in a company name control and then set visible = false.
The other way, is to CHANGE the name of the control to be DIFFERENT then the company name.
So, you can use add fields, but then in the other tab, rename.
So, say I just dropped in a Description column, but want to use left(10) on it
So, we do this:
Note VERY careful how I re-named the control.
I can't use left(Description,10), since that would refer to the VERY SAME control that I am attempting to use the expression against!!!
I would be saying, please use left of a control called description, but that description s the expression I am wanting to execute against!!!!
So, re-name the control. And now I can do this:
Note the arrow in above - note VERY careful how the control name is DIFFERENT then the data expression (Description) in this example.
Note VERY careful, I can now place OTHER controls on the report, and reference now:
I can reference Description in the expression, OR I CAN USE DescripitonLEFT in that expression!!!!
As you can see, we need a way to distinguish which control we are referencing here. In fact, some developers i have known as a habit NEVER use the same name for their controls vs the datasource of the control for this reason.
In your case the very same expression, and very same control BOTH have the same name - and thus you can't evaluate the expression of a left(Descripiton,10) against the VERY same control with the VERY same name!!!
So, you have to dis-ambiguate the name and the expression you want. In this case CompanyName. As noted, your left("some control") is the VERY same name as your current control.
Try just re-name of the control you dropped into the report.
I am trying to run a Business Objects report in 5.1.9.
When I refresh the report it asks me in a box labelled "Enter and Select Values"
I can either enter a single free text value in the text box or I can type % to leave it unfiltered.
I would like to specify several values in this box rather than one or all. How do I do this? I have looked everywhere on google but perhaps I have the wrong search terms?
Wow - 5.1.9 almost 15 years old.
The box you're seeing is a prompt. Prompts can be defined either in the report's query, or in a universe object that's used in the query.
If it's defined in the query, then it's easy to change. Open up the query panel via Data -> Edit Data Provider (assuming you're using Full Client, WebI is a little different). You'll see the query panel with result object in the top-right pane and conditions in the lower-right pane. Look for a condition that includes the text you see in the prompt. That condition will likely have an "Equal To" operator. Change that to "In List", and the prompt should then accept multiple values.
If the prompt is not present in the conditions pane, then it is most likely applied via a universe object. If you want to make this change for this report only, you could modify the query's SQL (but only if you're using Full Client; for WebI, you'd need to modify the universe as described below). Hit the SQL button, and you will see the generated SQL. First, check off the "Do not generate SQL" checkbox in the lower-left of the dialog. Not doing so will cause your changes to be lost. Look through the SQL for a #prompt() function. Within that function, you should see mono -- change that to multi, and close the panel.
If you don't want to change the query's SQL, or if you want the change to apply to all reports, then you will need to modify the universe object that produces the prompt. You will need to access to Designer, and permission to import/export the universe. You will also need to locate the object that produces the prompt. Once you do, change mono to multi as described above, and export the universe.
Have you tried entering either of the following?
"FreeText1";"FreeText2";"FreeText3"
or
"FreeText1","FreeText2","FreeText3"
(obvs replacing FreeText with whatever your strings are)
Users of a report have requested the ability to be able to manually enter a code, currently they are are presented a multiselect with all the codes related to the previous parameters.
This is in Report Builder 3.
This multiselect can become quite long so I thought another approach would be a searchable multiselect. Is this possible in any: way, shape, or form?
Could I allow for a cascading parameter (which is the code) to be either selected either through manual typing or another means.
I would add a type-in text parameter (lets call it Search_Code), with a default of % (assuming your data source is SQL).
Then in the data source for the Code list, I would add to the WHERE clause e.g.
WHERE Code LIKE '%' + #Search_Code + '%'
This will restrict the Code list to strings which partially match the Search_Code value (if entered).
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.
Suppose I have a field with a date value in a Reporting Services template, e.g. =CDate("2010.12.03"), I apply the "d" format to this cell, which, according to the description, "will reflect the regional settings of the report". I generate the report using the English language, the date is displayed as 12/03/2010, which is fine. Now when I export this report to excel, I have no idea what the __ happens.
First scenario: the regional settings of the computer are set to English (United States). When I open the excel document, the value seen in the cell is 12/03/2010, as expected. When I click on it, I can see that the actual value stored in the cell is 2010.12.03, which also seems reasonable - some formatting is applied to the cell, it's not simply exported as text. But when I try to figure out what type of formatting is applied, by right clicking and checking Format Cells, I see that the format is "General", i.e. none! How can this be ? This is Excel 2010 by the way, but the file itself is .xls, of course.
Second scenario, where it gets more interesting: now the region of the computer is set to e.g. Lithuania, where the date format is 2010.12.03. I open the same document and see 12.03.2010. Now that simply does not make any sense. Exporting many times I've encountered that sometimes the cell is formatted as [$-10409]m.d.yyyy in excel (under the Custom section). What is this, what does the 10409 mean ? The weirdest part of all: if I close the document without saving, change the computer region back to English (United States), reopen the document, the format is now [$-10409]m/d/yyyy ! HOW is this possible !??
Basically the same thing happens with numbers and with thousand/decimal separators - excel uses the region of the computer to format these, but the actual format of the cell can be something like [$-10409]#,##0.00;-#,##0.00 or General - again, depending on the region of the computer, direction of wind and the temperature outside.
My question is then, first of all, what the __ is going on ? Second, how should the excel document behave according to the specs, i.e. what does the statement that a format "will reflect the regional settings of the report" in the BIDS designed, where I chose the "d" format for the date textbox, mean ? Does it mean, that the format will be determined by the language of the report and the result will look the same on all computers in the world (which makes sense, since this is how other formats behave, i.e. if you export the date to a pdf, it stays the same always) ? If not, which appears to be partially the case in excel, why doesn't the exported date cell have the regional date format, i.e. the one that you normally use in excel, the one which formats the date according to the region of the computer ?
Are these some kind of limitations of excel or what ? Why can't we have consistent behavior, i.e. either make everything sensitive to the culture of the computer viewing the document or don't, why is the actual behavior somewhere in between ?
Excel uses a custom encoding for the date, and uses the machine regional settings as a hint on how to format the contents. The encoding is archaic, and has lots of specific, historic gotchas.
This means that the kinds of bugs that you see often do happen - you'll have data that's been exported to Excel, which then has its formatting and contents mangled once opened for the first time by the actual Excel application. The problem can be anywhere along the line - maybe the library that exports the data to Excel doesn't deal with some of the more esoteric historic cases well, or maybe Excel is confusing itself along the way.
I've had some success in the past with exporting dates as a strings to a CSV file, stripped of formatting, and then importing them into Excel/opening them with Excel.
I sorted my date formatting problem by:
adding calculated fields for the dates :
=IIF(IsNothing(Fields!Date_Delivery_Confirmed.Value),nothing,DateSerial(DatePart("yyyy",Fields!Date_Delivery_Confirmed.Value), DatePart("m",Fields!Date_Delivery_Confirmed.Value),DatePart("d",Fields!Date_Delivery_Confirmed.Value)))
set cell Textbox as dateformat
how I am using *dateformats (localised) I checked my server laptop and report are set to the right language
I have aligned elements vertically in the report so it ( the visual gaps) doesn't create extra empty columns when exporting to excel. Because 2 excel columns merged to 1 date-cell will never get any format but "General format"