Categories
- All Categories
- 15 Oracle Analytics Sharing Center
- 14 Oracle Analytics Lounge
- 213 Oracle Analytics News
- 42 Oracle Analytics Videos
- 15.7K Oracle Analytics Forums
- 6.1K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 78 Oracle Analytics Trainings
- 14 Oracle Analytics Data Visualizations Challenge
- Find Partners
- For Partners
Passing variables to detail report: IE vs chrome
I'm using OBIEE 12.2.1.4.0. In my master report, I've setup an action link for one of the columns. When a user clicks on a value in this column, it brings him to the detail report.
The master report has some presentation variables. I expect these variables to be passed to the destination report. This works fine in IE11, but not in Chrome 77.
Here's what is happening. In the master report, I define pv_category variable. In a detail report, I'm trying to use this variable in a filter condition, like this:
Category is equal to / is in @{pv_category}
In IE, the filter view in the destination report shows this, which is correct:
...and Category is equal to CLOTHING_CATEGORY
In Chrome, however, the filter view show this:
...and Category is equal to pv_category
So it seems that Chrome is treating this as a literal, not as a variable. Any ideas on how to solve this?
Answers
-
Try this syntax with quotes and check if it makes any difference:
(@{pv_category}['@']{'Enter a default value here'})
0 -
Well, I'm using the filter window. Whatever OBIEE is generating that's what is being used.
0 -
a) As Joel said you're missing a default value. It's always best practice to provide those.
b) If the variable isn't being populated then the obvious next question is: How do you populate the variable?
0 -
Click the "Convert to SQL" box, then edit it to try Joel's solution. Another syntax that works in some filters is @{dashboard.variables['pv_category']}. I've had to use that in Chrome for some situations.
0 -
b) If the variable isn't being populated then the obvious next question is: How do you populate the variable?
Well, it IS being populated. But only in IE, not in Chrome.
Forget the filter, I created a brand new detail script, and only put a single column just to print the value of this variable.
So when I tried this formula: @{pv_Category}['@']{'777'} - IE correctly prints the value, and Chrome prints the default value 777.
And when I tried this: @{dashboard.variables['pv_category']} - IE threw a syntax error, and Chrome prints 0.
0 -
Dimitry F. wrote:b) If the variable isn't being populated then the obvious next question is: How do you populate the variable?Well, it IS being populated. But only in IE, not in Chrome
Yeah but my question perists X-D
Shurt-cutting: did you check whether the prompt filling the variable is ok?
if you can describe in detail what you're doing, then I can test here
0 -
ok, so I have a master report and a detail report.
The prompt from the master report sets PV_Category presentation variable. Again this variable is working fine in the master report.
Then the master report shows a category column, which has an action link setup to run a detail report.
When a user clicks on a category value, it shows detail report - it works just fine. Except one thing - in this detail report, one of the filters is using that variable.
And the thing is it's not seeing its value, which was there in in the master report.
And this problem is only happening in Chrome. In IE it works fine.
0 -
and this is how the variable is being set in prompt
0 -
Clarification: You're really talking about "master-detail" inside an analysis with multiple views?
Because that means the whole entity is *one* analysis and would hence have a single set of filters which puts this in question: "in this detail report, one of the filters is using that variable"
0 -
Christian, you were right. The problem was in the prompt. It was a hidden one, and the default value was never assigned, so it was always empty. Once I fixed that, everything works in Chrome.
However that leads me to the next question - how come it worked in IE? I guess the variable was being set somewhere on the fly. I will try to find it out, however this report is huge, with 5 joins, and a very old one - folks who created it a long ago are not here any more. But I will try to find it out.
Thank you and everyone for the help!
0
