OBIEE Blog

Another good one.

Symptoms

You are on OBI 10.1.3.3.3 and have configured a Dashboard Prompt with a couple of columns where the value selected by the user in the first prompt column gets stored in a presentation variable, and the values in the second prompt column depends on
the value in this presentation variable.

When both column prompts are defined as ‘Drop down’ type. The prompts work
fine. The second column correctly displays in the dropdown the values.

However when the second column prompt control is defined as ‘multi select’.

ACTUAL BEHAVIOR
———————–
No data is displayed in the prompt. The prompt displays ‘No Choices available’.

EXPECTED BEHAVIOR
———————–
The multiselect prompt column should correctly display values in the prompt as it does when it is defined as a dropdown.

Cause

Statement describing the cause of the problem
This issue has been determined to be a bug, which is now reported in Change Request Bug No: 7571682 (MULTISELECT PROMPT AND PRESENTATION VARIABLE CAUSES ‘NO CHOICES AVAILABLE’).
The proof that this is the cause of the problem
This issue is caused by Bug No: 7571682 (MULTISELECT PROMPT AND PRESENTATION VARIABLE CAUSES ‘NO CHOICES AVAILABLE’) as per our inhouse testcase which replicated the same behavior your system exhibits.

Solution

This issue has been determined to be a bug, which is now reported in Change Request Bug No: 7571682 (MULTISELECT PROMPT AND PRESENTATION VARIABLE CAUSES ‘NO CHOICES AVAILABLE’).

As possible workarounds we have found that, on the Dashboard, when you click the ellipsis and invoke the multiselect popup and you get the message “No Choices Available.”,

1. Click the ‘Go’ button will bring back data

2. Alternatively you can enter a value in the match box and it returns data

3. Also you can consider using the vanilla constrain option for the dashboard prompts, so you can have column 2 constrained by column 1.

Please consider the above as possible workarounds.

While browsing web, I’ve found the following question:

“The query logs do show that there is a cache hit but the report still takes more than 1.5 mins to display. Why ?”

Solution offered

Checking the nqquery.log when the cache is hit, it was found the time elapsed between running the query, and getting the results was only 34 seconds
2008/10/20 07:17:38
2008/10/20 07:18:12

There is a defect logged to address the fact that you might see differences in the following measures for the same query:
-Time (Analytics web > Administration > Manage Sessions > Time column
-TOTAL_TIME_SEC (Usage tracking parameter)
-Elapsed Time (in NqQuery.log)

Elapsed Time (in NqQuery.log):
This is the total clock time it takes from the point SAS receives request to
the moment it gets data from SAW or ODBC client, until the moment data leaves
Analytics Server. Response Time and Physical Query Response Time are both
included in this.
These time parameters in NQQuery.log file do not reflect the time data spent
travelling between Analytics Web and Analytics Server.

TOTAL_TIME_SEC (Usage tracking parameter):
The time in seconds that the Oracle BI Server spent working on the query
while the client waited for responses to its query requests.

Time (Analytics web > Administration > Manage Sessions > Time column

Bug 7173446: DIFFERENCE IN TOTAL_TIME_SEC / ELAPSED TIME / TIME RECORDED IN MANAGE SESSION
This defect is targeted to be fixed in the next main release

Also it was recommended to change the following NQSconfig.ini settings which were set very high to 100000.. The recommended values are as follows:

MAX_QUERY_PLAN_CACHE_ENTRIES = 1024; // default is 1024
MAX_DRILLDOWN_INFO_CACHE_ENTRIES = 1024; // default is 1024
MAX_DRILLDOWN_QUERY_CACHE_ENTRIES = 1024; // default is 1024

Sometimes, we need to define an Aggregated Measure based on a Dimension Table.

If aggregated calculations are performed directly from a dimension logical table field, an error similar to the following will appear:

A general error has occurred. [nQSError: 14026] Unable to navigate requested expression: ). Please fix the metadata consistency warnings.

To resolve this type of error, put the measure indicated by the error message in a fact table object.

To define an aggregated measure of a dimension table, complete the following steps:

- Create a new fact logical table with the physical dimension table as source.

- Include all fields that should be aggregated as a measure of this new fact object.

In the Siebel Analytics version 7.5.3 repository, a good example is the Fact – Campaign Metrics fact table that is based on the W_PRG_CAMP_D physical table: