Set parameters values depending on other parameters

[Former Member]

Is it possible in the Bex to have a parameter to be used to load data from another infoprovider (then the one of the actual query) in order to populate a select-option in the query ?

- a Customer exit variable seems to be able to only change its own values. It have no access to the other variable and parameters ?

- Replacement path seems to only be based on kind of "hard coded and unchangeable" selections.

So how to do that ?

I also think to use RRI by doing a 1st query but I wonder if all the result of the 1st query (lets say all the orders numbers) could be transfered into the orders select-option of a 2nd query ?

[Former Member · Accepted solution]

Hi Bertrand,

not sure if I got your requirement correctly. But you can create a variable with replacement path and assign a query (with selections) to it in order to populate the select list for your query by another query.

Hope this helps!

Siggi

[Former Member · Accepted solution]

Hi Siegfried

>But you can create a variable with replacement path and

>assign a query (with selections) to it in order to populate

>the select list for your query by another query.

Yes but could I have control on the selections of the replacement path query and fill them in real time ?

I mean could my main query (the user lauching it) cascade its selection to the replacement path query ?

For example :

Let say that I want only orders that have a particular texts in description. The description lines are not in my main query infoprovider.

So could I have a parameter, let say "description contains word:" which could be transfered to the replacement path query in charge of selecting all the orders with the word in text ?

From what I understand atm of the replacement query the selections seems to be "statics".

[Former Member · Accepted solution]

Dear Bertrand,

in RRI, you can control the field transfer using Assignment details.

RSBBS->Assignment Details-> you can control each field to get transfered or not>>

hope it helps>>

regards,

hari

[Former Member · Accepted solution]

Hi Bertrand,

sure. You create a very normal query with all the selections (variables) you need to get the order numbers. This query you will assign to a variable with replacement path to populate the select-option for your order numbers. If you now run your query, it will show you the variables of your 'subquery' as well as the variables of your main query.

Siggi

[Former Member · Accepted solution]

Hi Hary

>in RRI, you can control the field transfer using Assignment

>details.

>RSBBS->Assignment Details-> you can control each field to

>get transfered or not>>

In the case of the RRI I don't need the selections of my first query to cascade to the main one. In that case I need the result of the first query to populate a selection in the second one. The assignement details as I can see it, only allow transfer of the selections (not the results).

[Former Member · Accepted solution]

Got it what you mean really now.. brain is not working now a days fast..

one interesting observation i made long back is to transfer all order numbers to the next query is

1. place the cusrsor on the column header.. (not on row..) and use goto option. but you know this is not good solution..

2. i think siggi option should work for you..

regards,

hari

[Former Member · Accepted solution]

>If you now run your query, it will show you the variables

>of your 'subquery' as well as the variables of your main

>query.

Ok ! Great ! Reading the documentation of replacement path I really didn't understand it like that so it's good news and it clearly respond to my needs. (now performances but this is another story). I'll test it in some days, thanks Siegfried.

The column feature can also respond to my need and might be far easier no ? But you mean it's not reliable ?

[Former Member · Accepted solution]

The column feature can also respond to my need 
and might be far easier no ? But you mean it's not reliable ?

Dear Bertrand,

I mean it may not be convienient to use it. But I have not observed it failing during my little experience.

nice to know that it can be a quick solution.

Regards,

Hari

• You can say 'thanks' by assigning small points

to the helpful answers.

[Former Member · Accepted solution]

Hi Hari,

Thinking at it, the solution of the column transfering data to select-option with RRI is more flexible. It can point to multiple reports I suppose and also the master report is not "slaved" to the secondary report.

Now for the user it's far less intuitive ...

PS : for the points it's fixed, it's just that I messed up with my 2 accounts and logged with the wrong so I was unable yesterday to do it

Message was edited by: Bertrand LAFOUGERE

Message was edited for spelling

[Former Member · Accepted solution]

wow! Very happy to know that it helped a bit to you.

cheers!

Hari

[Former Member · Accepted solution]

hi Hari,

Ok I've made a quick test to transfer the whole column of orders values to another query using RRI but it doesn't work.

I've customized the "tranfer only" of the orders but the RRI stop on the called report selection screen and with only the first order in the selection.

I've checked the following :

- in the source report I've clicked the column "order" in order to call the target report.

- in the target report the orders fields in selection are in a select option.

Do you have an idea why it doesn't work as expected ?

Is the stop at the selection-screen of the target query obligatory ? I've read that it's the case when one of the obligatory fields is not filled but they are all filled in my case ???

[Former Member · Accepted solution]

Hi Bertrand,

but at least the solution with the subquery must work. In our system it is working fine.

Siggi

[Former Member · Accepted solution]

hi Siegfried,

>but at least the solution with the subquery must work. In

>our system it is working fine.

The solution with the subquery has a drawback (well seems too have as I can't be affirmative on that but you migh light me ;).

Ok what I found unconfortable with the subquery is the case <b>when we use NONE of the selection fields from the subquery. In that case, tell me if I'm wrong, but the subquery will be launch anyway and will give back a full list with all the orders ?</b> Meaning poor performance and anyway somewhere not the wanted behavior (you know how the users are, they want everything with performance and all the options .

[Former Member · Accepted solution]

Hi Bertrand,

but you can create the variables for the subquery with the option 'input required' and forbid just the '*' input.

Then they have to restrict the values and performance might be ok.

Siggi

[Former Member · Accepted solution]

>but you can create the variables for the subquery with the

>option 'input required' and forbid just the '*' input.

Ok that's nice and could be a solution Siegfried. But the problem remain the same when users want only optionnals fields. However maybe can I move one of the obligatory field in the target query to the subquery like the creation date ...