I'm thinking that the dump includes ALL criteria columns ... if the purpose is filter only, try just having the column in the filter on the advanced tab and not in the criteria tab.

+1 to Mr. Berg ... Absolutely not the intent of OBIEE ... OBIEE is all about getting the summarized answer to the screen so business person can act/decide confidently and accurately.

Are there error messages in your log files? Did you set up Agents according to official documentation for your version?

First question is why export? Don't spend a lot of time hunting down a fix for known system behavior if this isn't a true requirement. Using OBIEE as the mechanism is terribly inefficient when you need data dumps to feed internal/external systems. BUT - is your column in the criteria AND the filter or just filter? This…

The builtin AGO function presupposes the logic to retrieve the data ... the trade is performance for flexibility. In your case the flexible function is a detriment to performance - so to get your performance you will have to model logically or physically (removing some flexibility) to get same results (with performance).

If you want 'sharability' in your data filters then your best approach is to implement as database tables and affect the row filtering via joins. Depending on how you implement data filtering you can have it part of the metadata in the RPD -- but if you do it this way; then they other reporting system will have to connect…

Poke around with this ... can't remember where I found it ... SELECT n AS Date_ID, TO_CHAR(CurrDate, 'YYYYMMDD') AS DATE_KEY, TO_DATE(CurrDate) AS DAY_DT, TO_CHAR(CurrDate, 'DY') AS DAY_NAME_SHRT, UPPER(TO_CHAR(CurrDate, 'Day')) AS DAY_NAME, TO_NUMBER(TO_CHAR(CurrDate, 'D')) AS DAY_OF_WK_NUM, TO_NUMBER(TO_CHAR(CurrDate,…

Use Gianni's framework and built out your security in EXCEL -- you can then 'see' the effective permission long before you ever start configuring and applying security. You can create stripes for all sorts of permissions and then have the opportunity to matrix them. It's a risk free way of planning.

My suggestion is to supplement the BIConsumer/BIAuthor roles with data security roles (and other permissions roles related to content) ... this gives you flexibility ... can have a user in BIDSAmericas (can see America region) and be either a BIConsumer or a BIAuthor. BIConsumer/BIAuthor/BIAdministrator are authorization…

if you are looking to display the intersection of date and run completion time, then you need a fact table keyed/structured that way. Use of information drives data model design. So you have options ... quick and dirty would be: tblETLComplete DATEKEY | Completetime* 20160807 | 445 20160808 | 530 convert the hours and mins…

Start with requirements; IGNORE tool functionality. -- you are starting over.

"OBIEE project and skillset are not in that demand" ... the principles on which this tool set was built are still in demand; it's not about the tool. One who doesn't understand the fundamentals will fail with any tool. What is an OBIEE Project?

Ego of the decision maker ... sadly. I've seen it too many times.

I think you misunderstand me ... I would never advocate a "migrating/copying like for like reports" approach. I also agree OBIEE is a much better tool that BO (at present) -- but OP probably has had this change imposed on them. So given that imposition - the best course of action is to go back to requirements and build in…

Start with requirements; IGNORE tool functionality. Whomever made the choice to switch tool-sets has to understand the functionality changes will impact organizational change management -- your ONLY controllable input is to implement the same business value (or more/better value) in the new tool -- pursuing…

CRM threw me off ... Why not have a date grained table that has your financial year details? then you don't have to mess around with adding and subtracting dates and performing functions in analysis columns. A simple TO_DATE at the year grain then gets you exactly what you want.

Looks like that KEY was key to the logical/physical model ... don't just go deleting willy-nilly. Since the KEY was being used as a logical key in the hierarchy, you've now removed the BI server's instructions on how to parse the hierarchy and aggregate measures to that node level.

This is a BI forum ...

Yes ... fire developer. Actually, appoint a MUD Admin who will create the measures (logical placeholders) and manage the projects. This person can also be responsible for migrating the MUD master to your development/test instance on a regular basis. There's no magic wand -- just a wee bit of discipline.

EMC docs show using a Postgre Unicode driver ... https://www.emc.com/collateral/software/white-papers/h8295-obiee-11g-analytics-emc-greenplum-database-wp.pdf