Or on the API thought, do what I have done previously and create a view with a trigger on it to handle the multiple table logic, makes it clean, safe, and keeps the DB logic in the DB.

Yes, you can even call a procedure to push the whole logic through an API equivalent, with writeback functionality being so limited I like this as an option partly for reasons of security, partly for data quality.

Btw - best is get your ETL / DW team to do what you are doing, so all of the pre-processing logic is where it should really be, and your BI remains clean and performant!

Hi, just apply the same logic to the underlying column as a function column that you is prompted is on, but change it to be based on a presentation variable, populating the presentation variable from your original prompt. Note also you do not have to display the column.

Not sure I understand your exact requirement but it sounds like you need to use some logic on the filter based on the value that is selected along the lines of; - Db.Debt like '%'||case when '{ValueSelected}' = 'TECH DEBT' then 'DEBT' when '{ValueSelected}' = 'ARCH DEBT' then 'DEBT' else {ValueSelected} end||'%' Note you…

The usual way is to rename your columns to user friendly equivalents in the business model layer, before exposing them to the end user. There is a wizard under tools that facilitates rapid / mass rename using rules - but note my caveat of before exposing it to the end user, as if the columns are already in use then the…

Try the following, reproduce your update code between the insert tags, I am sure I have experienced errors previously if I did not have both populated...

On 1 you just have to change the order such that the default weblogic takes first precedence. On 2 what version of OBIEE are you on?

You have probably checked this, but just in case, can you also confirm that the user your service runs as as the necessary rights on the file itself.

Have you seen => http://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=0ahUKEwjwqYzs6OXXAhVNaFAKHSzWDLIQFgh…

Why not default on your prompts? Otherwise, you are currently casting as a date and then treating it as a timestamp, you need to explicitly convert it to a timestamp. Not convinced your max requirement is achievable in a default, unless any knows otherwise?

I would also use a 'real' e-mail account, then you can have an administrator or programmatic equivalent check the inbox for notifications from e-mail failures, this can be a useful extra check for when people leave the company and the BI team are the last to know...

Not the most performant but you could concatenate the content of the two rows using a SQL statement, populate a variable with the result and use substring to separate out the relevant parts of the variable for the filters for the two columns. On your challenges assuming your data posted is representative I would only look…

Things to check; - What is the key to the conformed dimension for both tables. Do both facts return consistent results with the conformed dimension. If you ran the equivalent physical sql of fact - dim - fact with the joins you have created do you get a Cartesian product. - Generating the physical sql that is actually run…

Sure, but here in the real world I have been on more than one project where the DW was 'off the shelf' and the client was unwilling to pay for changes...

Hi Camilo, if there is no direct join between your two facts then your only option is to create a bridge table or sub-optimally an opaque view to emulate the same. By direct, I mean an trail which will not result in a Cartesian product when you utilise it.

Sorry, assumed you had some custom report method on the manage sessions functionality and were just asking on GO_URL download...

I agree on both counts, but was giving an answer from a purely OBIEE point of view, as the BI developer unfortunately you cannot always tell the DW developers what to do...

Yes there is, see => https://docs.oracle.com/middleware/1221/biee/BIEIT/apiwebintegrate.htm#BIEIT353 Downloading data in Excel. This is related to the syntax shown above but replaces the dashboard path with a report path, and adds syntax to download the data in Excel2007 (data downloaded is for prompted values only).…

"Facts should be joined by Conformed Dimensions" - well, if all the requirement is is to have the measure of one fact in the other fact table, and the tables are either 1:1 or 1:M then there is no reason you cannot alias the physical table that is used for the 'other fact' and use this directly to join and add the column…