Storing multiple parameter values in another parameter in SSRS - reporting-services

I am trying to develop a report in SQL Server Reporting Services using parameters.
I have created a searchable parameter (as described in the link below) which is working as it should. I want to expand the functionality so that I can make multiple searches before viewing my report.
My problem is that when I have searched and selected a value and seach for another value the selected is reset (this is because the parameter where I select is cascading to the one where I search). Is there any way I can 'save' my selected parameter so that I, in the end, have all the seached and selected values which I then can filter on?
Searchable parameter: http://romiller.com/2008/07/29/searchable-dependant-parameters-in-ssrs/
(My problem is the same as Peter Schmidts comment in the link above.)
Thanks

The only way I can think of to get the results you desire is to create separate dataset with a required parameter that depends on a search term from the other parameters...this is very hackish and requires a search on multiple values stored procedure. This would cause the report to postback after you select your search criteria then display another parameter dropdown after a second refresh where the user could select the desired id based on search terms and then finally clicking the "view report" button a second time.

Related

Use List Box with Multiple Selection in Query

Given I've created an Access Form with a ListBox; property > other > Multi Select = Extended; which permits multiple selections.
User selects multiple items.
Clicks a button that creates a report in "Print Preview"; but this report is based on the query, and the query is based on the values in the form.
This is accomplished by using this in the query when viewing in Access Query Design View (not SQL):
Like ([forms]![padc]![V2])
Where the form name is padc and the value to compare is V2.
Previously, rather than the ListBox that might show 10 options, V2 was just a field with one value. A user would either type a partial value, such as jack*, and the report would pull every instance where this value began with jack; whether that was jack, or jackie, or jacko, or jackson, etc. The LIKE part of this permitted the "fuzzy" logic bringing about varied results. The query would run, and the report would show all the records with anything starting with jack.
My goal, really, is to have a user select one, two or three, or all the available options in this box, and have the report respond correctly.
I believe the ListBox will let me do this, provided I have all the right names in the table that is the source of the options available to choose from.
I set the listbox to "multi-select" to enable multiple selections on the form.
The form is happy. It can let me click/highlight one or several items from the list.
The query is not happy.
For the field V2, neither
Like ([forms]![padc]![V2])
nor
=([forms]![padc]![V2])
Will retrieve records to populate the report; regardless of whether or not just one value in ListBox is selected or multiple values. (Like = fuzzy, and = means exact match.)
Neither work.
Of course, if the query won't perform, then the report won't perform either.
How can I write the correct query in Access, using "Query View = Design View" and or SQL to get this to function properly?
If the answer is "it can't be done without using VBA" then please point me to the VBA solution that a 5-yr old can understand, because I have zero experience using VBA.
Folks have recommended I use VBA; specifically that I should incorporate the "IN() IN function" in some manner; but I don't comprehend this solution at all.
I admit to being ignorant; not stupid; but ignorant.

Access 2016 drop-down list appearing in Reports and Queries

In Access 2016 I have a table called 'Orders'.
I also have a Form (also called 'Orders') that we use to enter order information. On the form, one field in particular ('Company') is a drop-down list. The control source is a second table called 'Companies'. And the Row Source is a SQL Query:
SELECT [Companies].[ID], [Companies].[CompanyName] FROM Companies ORDER BY [CompanyName];
So, when the user is entering an order into the Form, he/she can select the company name from this drop-down list and it in turn updates the Orders table. All basic stuff, and it works fine.
Next, I created a query (also called 'Orders') and it is based off of the Orders table.
When I run the query in Access and view it as a Datasheet, I was surprised to notice that the Company field (IN THE QUERY datasheet) is a drop-down list. Not only that, it even lets me change the value - right here in the query! If I view the SQL for this query, I can see that it is a SELECT query. In my mind, a SELECT query is read only. So my questions are - What's a drop-down list doing in a Query, and WHY does Access let me edit the values directly in the query? Isn't this supposed to be read only?
Next question:
After verifying that all of the data I need is in the Orders query, I then created a report (called 'All Orders') and the control source for this report is the Orders query. (not the table).
When I view the Report in Design view, there's the drop-down list again. Why? I am just looking to add the Company name that the user selected when they completed the form. I realize that the form Control for entering that data (on the FORM) is a drop-down list. But here I am building a report and I just want the VALUE to appear here. Not the drop down control? (I know that when I print the report or view it on the screen, the drop-down boxes go away and all I see is the actual text). But my question is - WHY is Access showing me a drop-down list control on a report? and in a select query? The query and the report are no place for editing data. I just want the value that was selected.
That's because you've defined the lookup list in the table. If you do so, it propagates to queries and new reports and forms, and will be the default way to view the data everywhere you've placed it.
Open your table in design view, and change the display control for your field back to text box. Note that any forms and reports will need to be edited or recreated, for queries the change should propagate.

MS Access: Passing Parameter to Subreport w/o SQL

I'm trying to find a way to pass a parameter from a report to a subreport without resorting to any SQL code or macros (my officemates are non-technical, but still have to use the Access database to run reports, occasionally making tweaks to them.)
I'm working in Microsoft Access 2013. I have a table that contains a list of investments as well as which state those investments are based in. I have a query that pulls data on Investments based on a user-entered State parameter. I then run two reports: one that simply lists the investments grouped on different categories, then a second report that summarizes the investment categories into a table. I've put the summary report at the top of the detailed report as a subreport, but I want to pass the State parameter through from the main report to the subreport so the user doesn't have to enter it twice. Is that possible without resorting to writing any SQL code or macros?
Thanks!
I think I understand what you're trying to do, but please add details if my answer doesn't make sense.
You can pass user entered information by referencing by
[DatabaseObjectType]![ObjectName]![FieldName].
If the user is entering the State value from a Form, you'd reference:
[Forms]![FormName]![State]
where FormName is the name of your form, and State is actually the name of the Form control containing the State value.
If the user is entering the State value in a prompt from a query, you'd reference:
[Queries]![Query1]![State]
where Query1 is the name of your initial query that gets the state info from the user, and 'State' is the name of that field.
You put these references in to your secondary query or report:
for example, in a second query, you can set the State field Criteria (in query design view) to be = [Queries]![Query1]![State]
so the second query will pull the State value from the first query
on a report, similar idea - you can set the Control Source of the State control (in Properties) to be = [Queries]![Query1]![State]

BOBJ Webi Prompt with a specific subset of values

I'm creating a webi report and have a few prompts defined at the query (not universe) level. Unfortunately, the prompts return a butt load of values due to the design of the table. What I'd like to do is restrict the list of values presented to the user based on a set of criteria. Is there any way to do this in the query? I'd like to avoid creating a specific prompt in the universe.
Thanks
In XI3, there's no way to do this without touching the universe. In the universe, you can modify the LOV logic for a particular object -- click the "Properties" tab, then "Edit" under "Associate List of Values". This will present a standard query panel; you can add conditions here, and the conditions will be applied whenever the LOV is displayed in WebI. Note that this action will only affect the display of the LOV; it will not have any effect on how the SQL is constructed to generate the report.

Multi value parameter in SSRS 2008

How can you tell what value was selected first in a multi value parameter in SSRS 2008?
Example
a,b,c
are the values
and I would like to know if b was selected first and if so change the string to be b,a,c
If you mean tracking which value a user clicked on first in the web interface, then you can't get this functionality through SSRS. A multi-value parameter doesn't preserve this order.
A few workarounds come to mind:
Create multiple parameters
Create multiple parameters such as "Primary BU" and "Secondary BUs." You could even remove items selected as primary from the secondary list.
Create your own interface
You can always create your own "Report Manager" interface and then call reports and serve them yourself. You get complete flexibility over the UI, but still get SSRS to handle data, report creation, and export formats.
Javascript hacking
The SSRS webpage is a webpage after all. In theory, you can insert your own code. I wouldn't recommend this, as updates may break your code though.