And what error are you currently getting? (you are my hands and eyes!)

Also, can you explain the purpose of 'add-ons' - is this snowflaking, if so when you modelled the business model layer did you drag the outer table onto the inner dimension and define the nature of the join that way? (if it is correct you will only see one Logical Table Source on the dimension in question, but when you…

Hi, looking at the physical structure something that does not seem right is; - Account (Fact) -> Partner Client (Dimension) Account (Fact) -> Calendar (Dimension) Partner Client (Dimension) -> Calendar (Dimension) Dimension to dimension should not be, unless this is some kind of snowflake (?) in which case I would expect…

This is worth a look -> https://www.peakindicators.com/blog/20-golden-rules-for-the-obiee-11g-rpd

Ok, you need to provide what I ask for or I am left in the dark. But in terms of general advice; - 1. Ideally each fact should join to each dimension via a foreign key (fact) to prime key (dimension) join, or sub-optimally via a complex join equivalent 2. Each logical dimension should as minimum have a dimension hierarchy…

Btw - I would never expect to see a direct join between 2 fact tables - payment / account above - if your previous diagram is correct?

Yes it is, but I need more to be able to help you!? Errors? Joins? Logical equivalent of what you posted? Content levels?

If you can give us more detail on your physical joins, keys and content level settings and your exact error message(s) then we can probably help.

Nice article! Amazing how many production systems, typically implemented by major consultancies, where when you come to look in the rpd and the content levels and number of elements on dimension hierarchies have not been set. 10 minutes work later and there is a massive performance improvement and things stop erroring.

What Gianni is telling you is that for the dimensions NOT joined to the facts in the table you need to use their content level to set to TOTAL level against the fact table that they are not joined to. Hope that helps with the cerebral explosion rather than making it worse.

Know the feeling - glad you got there!

I have used this successfully previously. I also find the view sql / view parameters useful to use on the landing page whilst you are trying to diagnose exactly what is being passed / not being passed.

Yes, I am not suggesting they should be, I am suggesting you create a separate dashboard prompt on that page and hide it. So cosmetically the experience will be the same for the end user, but behind the curtain you will have this extra logic.

Could you show some screenshots of the key elements of the solution please so we can see exactly what you currently have? Key elements :- placing of the action link, configuration of the action link. You can / should hide any detail that is sensitive for general consumption.

You really don't need to use GO_URL if this is 'drill' behaviour on same subject area. All you need is 'Is Prompted' on the target report and an action link for navigate to report on the data (not heading) If you find that one column is ignoring the drill specific to the data then add a local dashboard prompt and use that…

Sum if versus filter by aside; if you have access to the rpd then you can duplicate your existing count of applicants measure, call it Count of Applicants by Job, pin (copy and paste) it to the job level (detail probably) of your associated dimension Job, then the number will be invariant for each job and you will have a…

Is this what you are looking for -> https://gerardnico.com/dat/obiee/obis/logical_sql/group_by

See -> https://gerardnico.com/dat/obiee/jobid_inconsistent

See s_nq_jobs https://docs.oracle.com/cd/E14571_01/bi.1111/e10541/schedconcepts.htm#BIESG1426

My first big job with OBIEE was writing ETL and associated rpd development for e-Business GL, AP and PO. When I first saw OBIA I thought, "I wonder how the professionals did it?" The answer, sadly, was whenever there was a difficult bit they invariably ducked the question, and even though I had been mid-way on the OBIEE…