When you say 'exactly that' you mean; - 1. Duplicated base existing measure 2. Change name to Year Total (or whatever) leaving aggregation as sum 3. Dragged Year Total Measure to Time / Year dimension hierarchy level to make its level Year Yes?

Check your Logical Table Levels settings between the fact and the dimensions it joins to. Check your keys on the dimension hierarchies are actually unique. Also, try experimenting with 'server complex aggregate' on, on the measure.

You could also create a new rpd column based on the original physical measure and add a case statement to filter for the value by only if year - 2017. Again this would need pinning on the time dimension to the Year level, if you want it to be invariant, or leave it at detail level if you do want it to give you a different…

Hi, when you say; - "whole cumulative amount for the last year" do you mean - Sum(Jan:Dec) or do you mean Sum(Jan:CurrentDate) Assuming Jan is your start of year. If you mean the former of the two then just duplicate your measure in the rpd and pin it to the Year, and when you display it with 2017 it will be Full Year…

It might also be worth checking with your local network support to ascertain if there have been any network / DNS or similar issues recently.

No offence taken, apologies if it read that way! And yes, 3NF modelling is heavily sub-optimal by its very nature!

Agreed on case 1 - but believe it or not I have been presented with exactly what I described from a 'Big 5' consultancy, sold to the client on a country wide basis as 'off the peg'. Reality sure is sub-optimal sometimes! On case 2 that presumes that the shared keys exist at the correct granularity to facilitate the join as…

Hi, Case 1: Both facts have a key that means that they can join directly without altering their data granularity and without loss of data. In this less than normal case you can join directly, usually by dragging one physical table on to the logical table source of the other in the BM layer. Case 2: Both facts share one or…

Mine was the initial same thought, but the note of "should only be used when a certain dimensional field (degenerate dimension) is being used" bothered me - usually when I have modelled fragmentation it is time sliced, like a union (all) query between two distinct data sets, with each having full data for its periods.…

Not all databases support the same features, so if, for example one source is MySQL and the other Oracle DB then the results could be very different in terms of the physical sql, OBIEE compensates for limitations of underlying databases.

Sorry, just seen "in a calculated column" - if you do (for example) x / y or similar then the result may not be an int, I would suggest that you need to cast your int to a numeric type that can handle it in the analysis formula if you are doing anything that could result in decimal places.

Use the query tool within the rpd to query the column across to the alias (if there is one) to the logical table and make sure the data type change that you have made is consistent across all.

Hi, in the physical model of the rpd you can change the datatypes of columns. Simples!

Thanks, hope your project comes together and the end users don't try to move the goal posts...

if you are just looking for a sandpit then; - OBIEE Samples

Is this the kind of thing you are looking for => https://www.clearpeaks.com/obiee-data-api/

Direct database requests are not supposed to form part of your wider end user experience - they are more meant for admin level queries, they do not leverage the wider benefits of using OBIEE. If it becomes a regular business requirement then invest the time in modelling a fully formed OBIEE rpd based solution.

There seems to be an on going trend for over-engineered BI where the client wants very specific look and feel to be 'X' so the developers wind up hand crafting code which is expensive to create, more complex to understand, frequently results in sub-optimal query performance and is far from best practise. My preference is…

You would be better on the OBIA forum for this.

Nice, you could combine this with usage tracking data via an exists in another report filter and then it would provide the full 'ask'....