I am using JasperStudio 5.6.0.final and the report is not generated dynamically from java code.
I have a problem with getting single value from parameter.
In the report I have a parameter A of a type List.
It is not a problem to use it in a clause as IN statement:
AND $X{IN, USER.ID_USER, A}
But I have a problem to get a single value from that list.
I know that my List has always 10 values.
So I want to use it in query, but I don't know how to write the statement:
AND USER.ID_USER = *first_value_of_list_A*
e.g.
AND USER.ID_USER = $P!{Atrybuty}.get(1)
doesn't work
I tried also to assign parameter value to a variable, but as I know it isn't possible to use variables in queryString.
So my question: How to get single value from parameter List in queryString.
What you need to do for this is use
AND $X{IN, USER.ID_USER, A}
Set A type as Collection and that will allow you to even have a single selection or multi selection or just a single value.
Hope that this helps.
Related
I have a stored procedures which receives a list of ItemId's. If the list only contain one item this works:
AND (#OrgItemIds = -1 OR ...)
AND (#OrgItemIds = -1 AND...)
but if the list contains more than one item it crashes.
Anybody knows how to fix this? Can I check the size of the list somehow?
Or can I check just the first element of the list like #OrgItemIds[0] or something like that?
There is no "comma-separated set of values" or "array" datatypes in SQL SERVER. You handle the parameter as a scalar variable in your code. Thus when you provide a single value in that list, server implicitly converts it to int and your sp succeeds.When you provide string with commas - it becomes impossible to convert it to int.You have to manually parse your argument, put it into a table variable and then use this table in WHERE clause. Or change handling of this argument to support a string of values instead of scalar value:
... where #OrgItemIds like '%,' + cast(t.OrgItemIds as varchar(10)) + ',%'
which is much worse for performance than filtering by id or list of ids.
I have a project that I need to add a param to that accepts multiple values. While this should sound pretty easy it is not working.
Here is the param: #queue_group varchar(100)
And here is how it is used: and g.extension in (#queue_group)
Now when I manually do it like so: and g.extension in ('700', '702') it works just fine. I have to make the numbers a string because of how the column was setup it has some string values in it such as *86 that breaks when I just do 700, 702.
Now I set up the param in SSRS giving it available values and allowing multiple select but every time it doesn't work because it can't find any results. The ultimate error is a divide by zero which is because it isn't finding any records.
How can I make SSRS mimic my manual behavior of '700', '702' which when I remove the param and enter that manually it runs just fine.
In SSRS I've tried Available Values CS = 700, CS = '700', CS = =Cstr(700) and CP = 702, CP = '702', CP = =CStr(702).
I've now tried setting up a table and using that as the defined values for the parameter. It now works when I select a single option and returns results. whenever I select 2 it returns me 0 results.
I'm at a loss.
SSRS can support multi-value parameters without much extra work so long as the dataset is in ssrs.
Here is a link to the tech net on it:
https://technet.microsoft.com/en-us/library/aa337396(v=sql.105).aspx
What happens is that SSRS passes the whole query to the sql compiler, this means that the replacement of the parameter with the multi-value string happens before compile. So I don't think that's the problem, because If it were an error in the way the multi-value param was presenting the data to the compiler it would not be a divide by zero.
Instead I'm thinking this has to do with how the parameter is populated. You have the param set to a text field, so people are expected to enter their own values. However SSRS handles the formating for a text field before it's sent to compile, and I'm guessing that's what tripping you up.
If you enter "402,407" without the quotes into the param at compile time it will be transformed into:
and g.extension in ('402,407')
That would not return any results. If this is just a report you use, you could enter: "402','407" without the double quotes and at compile time it would transform it too:
and g.extension in ('402','407')
The better solution would be to create a data set for the param, set the parameter to use that data set as it's list of available values, and check the multi-value property for the param. That way you would select multiple values from a drop down, and the user wouldn't have to mess with the string formatting.
I have two datasets in my report and data is being displayed through a table. When I give expression like below:
=Format(Fields!InvDt.Value, "dsRepSalesReport_tblPrintSalesReport","dd/MMMyyyy")
It says there is Syntax error. If I remove dsRepSalesReport_tblPrintSalesReport part, there is no error.
1) Please advise how to wite the expression in format with aggregate expression.
2) If I write expression without dsRepSalesReport_tblPrintSalesReport part, my table repeats data and shows for all invoice. But when I add aggregate part, dsRepSalesReport_tblPrintSalesReport
Table just shows one value several times.
Please advise how to handel with these two issues.
Thanks
The method signature for Format is:
Public Shared Function Format(
ByVal Expression As Object,
Optional ByVal Style As String = ""
) As String
So that means you can't just specify the field and the Scope as in your first example; the first of the two arguments must return one value only.
In your example, you could use something like:
=Format(First(Fields!InvDt.Value, "dsRepSalesReport_tblPrintSalesReport"), "dd/MMMyyyy")
Which will format the first value in the specified Scope.
Another option would be to just set the value as required in the report then use the Format property:
It's difficult to answer your second question without knowing what your data/required results are... If you update the question with some simplified sample data to illustrate the actual issue you're facing that would be helpful.
I have a situation where I want to make a drop-down parameter visible only if a previous multi-drop-down param. has one choice chosen(out of many choices).
Wht i've triedso far is to set the Default Val. for the drop-down parameter to be this:
=iif( Parameters!AccountIDs.Count >0 , 1, Nothing)
But it's not working. any tips appreciated, thanks
You won't be able to make a parameter disabled or enabled like this. (At least not without getting really complicated and hacking the page a bunch)
But you can make the second parameter have dynamic available options. Then make it just a sinlge option such as "<Not applicable>" and select that if the earlier parameter has multiple values.
You will need to create a dataset that returns the available parameters. Something like this might work:
SELECT
'<Not Applicable>' AS ParameterValue
WHERE
#ParamOneCount > 1
UNION ALL
SELECT
SourceName
FROM
someTable
WHERE
#ParamOneCount = 1
(You could change replace the second SELECT with multiple selects to have multiple hard coded values.) Then in the parameters for this dataset, set one of the parameters to be called "ParamOneCount" and set its value to be =Parameters!Account.Count
I'm having a problem when working with multivalue parameters between reports.
I have a main report in which I have defined a multivalue paramer, which I use to run a SQL query to populate its dataset. The parameter is used in the WHERE clause in the following way:
WHERE values IN (#parameter)
It's working fine and it retreives the expected data.
Then this main report passes this parameter to a subreport. The parameter is also defined as multivalue in the subreport and, as far as I can see in the parameter's dropdownlist it receives the values in the right way. Something like this: A, B, C
The thing is that the query that populates the subreport's dataset returns nothing.
It also has a WHERE clause defined as in the main report (which is already working)
WHERE values IN (#parameter)
If I run the query manually, hardcoding the values to something like this:
WHERE values IN ('A', 'B', 'C')
it works, but when I try to use the parameter it doesn't. So, somehow it's losing the format or the values in the way.
I tried this solution in the subreport's dataset definition, which was proposed in another thread:
=join(Parameters!<your param name>.Value,",")
But it doesn't work for me, the dataset is still empty.
Any ideas about what I'm missing?
Thanks! :)
This should "just work." Make sure that the Parameter in the subreport is set up as multivalue, and I usually use the exact same query as in the parent report to provide "Available Values."
Check that you are passing the entire parameter to the subreport: In subreport properties on the parent report, the parameter's value should read [#MyParamName] not <<Expr>>. If it reads as the latter, edit the expression and make sure it doesn't have a (0) at the end. but =Parameters!MyParamName.Value is correct, not =Parameters!MyParamName.Value(0)
Just created the report from scratch again and it worked. I must have forgotten something in the middle.
Anyway, just in case somebody needs it, the two parameters, the one in the main report and the one in the subreport , must be defined as multivalue.
Then in your query you should use IN in your WHERE clase, something like this:
WHERE field IN (#parameter)
And nothing else is needed. I didn't need to do the following:
=join(Parameters!<your param name>.Value,",")
It just worked for me
I think I know what you did, as I was drawn here by having the same problem.
The subreports were setup fine, but when entering the parameter binding in the parent report, the Value drop down did not offer my parameter, so I used expression builder to select it. This left the grey << Expr >> marker in the value and would only work when I had only one value selected from the list. When I replaced this with [#MyParam] it worked fine regardless of the number of values selected. When I had a look at the value expression builder had created a bit closer it had =Parameters!MyParam.Value(0). Removing the (0) also fixes it.