Let me google that for you...

Use of information drives data model design ... you need to put the 'configuration' of your calendar into your Time dimension table and model it for how you are planning on using it. You can 'house' more than one calendar in a Time dimension as the grain is the same (a date is a date is a date) ... fiscal calendar, ad…

It's a separate Business Model - that assumes you are going to logically relate things differently. The bigger question is why the need for the second BMM? 

ok good ... so how are you determining that your cache is being purged?

check the cache settings on your individual physical tables/aliases in the RPD ... perhaps they were set up to expire daily/hourly/etc

BI Apps is pre-built ETL/ELT, DW schema, metadata and catalog content. You are correct on performance and security considerations - it's an additional layer to be managed. Is the VALUE worth the risk and cost to manage? 

Here's what Tableau themselves say about it: http://kb.tableau.com/articles/knowledgebase/tableau-and-obiee Risk: users can circumvent the enterprise model and create their own version of the truth + the connection to the BI server isn't really optimized and much of the functionality you purchased with apps may not be…

Did you try directly referencing the port? http://localhost:9704/analytics

A leading practice in OBIEE is to alias all your tables in the physical layer ... then you can actually have a 'star'; you'd be joining facts but you'd be joining the dimension alias of that table. While it might seem a case of semantics, it helps to preserve the 'theory' in the diagram.

why are you joining Facts to Facts? think in terms of star schemas. facts are related through conformed dimensions, dimensions are related through a common fact.

??? If the two reports are completely different, how could you ever sort one the same as the other? You must have some commonality...

you'd be better off with a common code for Fuel/Propane and a units of measure (UOM) column (the account numbers are getting in your way) ... then you can do the FILTER() referenced above, in the RPD, and consistently get the calculation of average dollars per gallon independent of the account number. IE: Row Account_num…

Isn't this a duplicate of your other post? Passing value from one prompt to other prompt between pages in dashboard

A connection pool can handle the DSN, USER and password (this one is highly inadvisable) as a session variable. Use VALUEOF(variablename) ... Consistency check doesn't actually attempt a connection nor does it do a syntax check for your DSN string. Oracle uses variables for the connection pools in it's OBIA offerings

A time dimension should be built so it is conformed across all your facts ... then you can relate factual data across time. IE: number of positive tweets rising over time and sales dollars rising over time

You need a Time dimension table joined to your fact table ... OBIEE won't make up data

Best to have your time dimension structured physically and loaded in ETL ... doing calculations to get the levels will prohibit you from using the time hierarchy as a true time hierarchy with chronological keys and thus limits you from using time series functions (AGO, TODATE, PERIODROLLING). Use of information drives your…

SampleApp has a script that reads through the XML of the catalog and gives a data file of each report and it's references and whether those are valid or not. It's call ReferenceChecker....

Passing the UNION from the presentation server to the BI server is about the most inefficient and least functional way to do things. Try changing the logical and/or/ physical data models to achieve the requirements -- the use of information drives the model (both logical and physical) design. BUT here's how one person was…

did you try something like: http://gerardnico.com/wiki/dat/obiee/connection_script using: SET PDQPRIORITY {DEFAULT|OFF|LOW|HIGH};