Don't think you can do this as one step, but you can use usage tracking to compile a list of which subject areas are being accessed and then use this in the rpd to query which tables are being accessed by individual subject areas. Alternatively you can access the log files to pull the physical sql out, and then wade…

On re-reading his post, yes, I think you are correct, my mistake, on first reading it looked like he wanted two things to be true simultaneously which were not compatible, so yes, your answer is what he is looking for. I know the ideal situation is 1 join between fact and dimension and job done, but I always found it odd…

Sure, customizations, see => https://docs.oracle.com/middleware/12212/biee/BIESC/GUID-351F0594-047C-489B-A4B7-9779A0088574.htm#BIESC6005

Hi, if you want the same table for two purposes then you need to alias it twice and model the first using your first join condition, the second using your second. You might also want to look at using lookup tables depending on your precise requirement.

I was not suggesting an 'exotic workaround' - I was suggesting that suppressing the data at source would resolve a requirement that seemed on the face of it fairly odd, why is week 53 populated with data if it does not exist in the years in question??

Hi, I don't think you are understanding me, I am saying to put a filter on your entire report content, which is the equivalent of; - Week No <= 52 for non-leap years, Week No <= 53 for leap years. So week 53 would only appear when appropriate, you only need one filter! So when 1 is true you will see weeks 1 to 52, other 1…

If your report is just displaying one year (you do not say) and there is a week number column then you could use some function based logic to determine if the year is a leap year and generate 52 if not 53 if so and put that in conjunction with <= logic on the week number, to filter the report to 52 or 52 weeks. Week No <=…

The correct corresponding version downloads should be available from the home page when you log into the front end of OBIEE.

I am not understanding your statement; - "analyses won't work when 2 of the prompt filled, it can only work if one of the prompt filled so the other value would be aggregated" - can you explain further? - measures are just about always aggregated so this is not making a lot of sense to me Can you be explicit on the exact…

You might also want to try it as a session variable.

Hi, you might want to double check that the connection pool in question has not been blacklisted, I have seen this a number of times where server variables cease to work due to temporary (or permanent) connectivity issues.

Yes, you can also have multiple physical data sources for the source of a single logical table.

Hi, the only time I have seen this is with migrated reports for which you might want to try a SR with Oracle Support, does your issue happen for reports wholly newly created in 12c?

No, you cannot use excel macros in the rpd, what are you trying to achieve??

However, suppose you invest months of development and create your interface and then Oracle upgrades and you find that something integral to your solution no longer works.... Would you really build your castle on sand?

In addition to Gianni's comment - If it is possible to link from Fact1 to Fact2 via a shared dimension(s) then provided you only construct reports that utilise measures from the facts and attributes from the shared (conformed) dimensions then it will work. (And set appropriate content levels on the LTS)

Hi, put your case statement in a formula in the front end, make it the first column, apply sort descending, hide the column. You don't need to hack the XML for this. If I had to hack, I would hack the SQL for this, and reference the columns explicitly not via the aliases.

You said that so loud it echoed...

For future reference you can also create a single union (presuming they are all variations on a theme) and then alter the sql directly to make the creation of the mass union less labour intensive, note you need to do this BEFORE applying any formatting because the minute you apply the sql you will destroy any work you have…

Hi, if you go to the advanced tab the XML represents the entire report content. You can do a copy and replace in your notepad of choice and then paste it back, the only gotcha to watch out for is line wrapping in the wrong place which can make the XML invalid, but I have done this previously for a similar problem and…