I need to make cascading of prompts in BO XI Rel 2.
I have created cascading LOVS in the designer as:
For this 3 hierarchies objects:
“Activiy 1 Name”
"Activiy 2 Name"
"Activiy 3 Name"
The designer has created required lovs and found in “Edit” lovs option.Found query formed correctly using @variable.
Now what I need is, want to create 3 prompts using @Prompts in designer and use cascading of prompts feature.
Created “Prompt for Trader 1” ,“Prompt for Trader 2” and “Prompt for Trader 3” using :
Syntax:
TRADER_1.TRD_1_CODE IN @Select(Level 1 Trader\Level 1 Trader Desc)
Repeated same for 2 and 3 for Trade levels.
When I am using this prompts in the reporter, it is not showing the correct query and not forming any cascading of prompts( I think I am missing some thing ).
Can you please. explain how to use cascading of prompts in the BO XI?
Any POC/ reference docs will be very much help full.
In XIr1, the Business View Manager is used to create cascading list of prompts, and as Michael stated they were usable only in Crystal Reports. In XIr2, those same cascading prompts can be used in Live Office. Additionally, in XIr2 it is possible to build cascading prompts in universes with Designer, meaning they can now be used in Desktop Intelligence and Web Intelligence documents as well.
But, I suspect that the cascading prompts have the same flaw that they have in Crystal Reports – that the “higher levels” of the prompts only restrict what choices you see in the “lower levels” of the prompts – and do not ultimately impose a restriction on the rows returned – can anyone confirm that?
I.e., let’s say you built a cascading prompt for Country - City – and both the U.K. and the U.S. happened to have a city named London.
If your cascading prompt started with Country and ended with City – and you picked U.K. / London – the condition would only limit to the City “London”. So - the data for London, U.S. would still be returned unless you explicitly imposed the limit for Country as well.
I guess it might be nice to have an option … create higher level conditions (yes / no) … but I don’t think I would want it to be automatic. It is reasonable to me that the report designer should know / control where the higher level conditions are required.
Let’s think about how this works. Conditions use LOVs. LOVs don’t create conditions. LOVs are often generic. They are based on a specific database object, but can be applied to many different database objects. Classic case would be LOV based on a dimension table, but applied to a field on a fact table. I can’t really visualize how this “automatic higher level application” would be possible … at least not without a lot of complexity.
I understand about the possibility of LOVs being generic – but oftentimes, folks don’t make them so. And the lack of an option to have cascading LOVs impose the limits that appear to be selected can be deceiving.
So – I agree – let’s have a way for the report designer to choose, but make the choice possible.