Short-version: When drilling to a report where some parameters are left unspecified in the drill-through definition, the prompt selection from the previous run is remembered.
Long-version:
We have two reports displaying similar data in different formats, one graphical and one list-based. The user is allowed to drill-through between these two reports (both directions).
Both reports have a lot of parameters/prompts, all optional. None of the prompts have default selections. The parameters in the two reports are mostly the same, but the list-report has some additional parameters which are relevant only for the list-based view. The setup is something like this:
1) Graphical report 2) List-based report
Param A Param A
Param B Param B
Param C
Now, when drilling between these two reports, the desired functionality is that the common parameters (those existing in both reports) are carried on in the drill-through, whereas prompts/parameters in the target report that don't exist in the source report are left unselected.
Based on the setup above, e.g. when drilling from report 2) to 1), the (possibly empty) values selected for Param A and B in report 2) should be selected when drilling to report 1). This is working as expected, by specifying parameter values in the drill-through definition (target parameters are set to their source parameter counterparts).
The problem is this: When the user in Report 2) selects a value for Param C, updates/reprompts the report, then drills to Report 1) and then drills back to Report 2), the value for Param C is still selected. We want this to be reset (nothing selected). I.e. Report 2) seems to remember the previous selection on Param C, even though the user has drilled away from the report and then back again.
In the drill-through definition specifying the drill from Report 1) to Report 2), we have tried leaving the value for Param C to both "(default)", "do not use parameter" and "" (empty string, taken from constant in underlying query), but the parameter/prompt value selected in the previous run of 2) still remains selected when drilling from 1) to 2).
We suspect this is related to prompt (or report) caching. Is there any way to disable it completely? Any other suggestions?
All help is highly appreciated.
I haven't tried this, but...
...how about in Report 1, you create a parameter that never has a value. (and make it optional)
i.e: ?p Blank?
...then, in your Report 1 drill through collection, map the ?p Blank? parameter value to your Param C in Report 2.
in theory, by explicitly passing through blank (or unspecified), maybe it will reset that parameter in Report 2
Use javascript to reset the prompt value when the prompt page loads
Thanks for the replies.
@david.stachon:
We tried the "blank parameter" approach without luck, even when a parameter that never has a value is specified for Param C in the drill through definition, the previous value in Param C is remembered.
@Gopinath:
As for the javascript approach, we were hoping to avoid having to do custom javascript, but I understand we may have to look into it. Do you have an example of how this is done?
Place a HTML item next to the prompt and paste the below code
<script language="javascript">
var fW = (typeof getFormWarpRequest == "function" ? getFormWarpRequest() : document.forms["formWarpRequest"]);
fW._oLstChoicesPROMPT_NAME.selectedIndex = 0;
</script>
Thanks!
This type of custom javascript accessing internal (and undocumented) Cognos variables is, however, just what we are trying to avoid. When we upgrade to a later version some time in the future, it is quite possible that all such HTML/Javascript-items must be changed. That is a risk we cannot take.
Also, I suspect this will only change the selection in the prompt control (after the page has loaded), and not change the value of the underlying parameter (and thereby the result of the query that is run). The prompts that need resetting are on the report page itself (no prompt page), and thus we need the parameter values to be reset before the queries are run and the page is populated with report components and prompt controls.
I've run into the same problem. A very ugly, but effective, solution would be to create four reports.
1) Graphical
Param A
Param B
2) Graphical1
Param A1
Param B1
3) List
Param A
Param B
Param C
4) List1
Param A1
Param B1
Param C1
Graphical would drill to List which would drill to Graphical1 which would drill to List 1 which would drill back to Graphical. The parameter names have to be different, or the problem will continue.
This way you are not making any changes to the way Cognos handles caching, you're not using any unsupported Javascript items, and you're ensuring compatibility with future versions. The downside is that any changes made to the report needs to be made twice.