Illegal cross join within the same dimension caused by incorrect

Hi,
I created a logical table from 2 different Physical tables. Then I created a Dimension out of this logical table.
At the BI Answer, while I tried drilling on the dimension, I get the following error:
“Illegal cross join within the same dimension caused by incorrect subject area setup “
Please let me know if there is any work around this issue.
Thanks,

I think that OBIEE try to do a cross join but don't allow it
http://gerardnico.com/wiki/dw/join/cross_join
It generate surely a join with two tables where you don't have any condition or relation in the physical layer.
When you check the column from the subject area are you sure that you have a condition in the physical layer for the two tables ?
When you say "I tried drilling on the dimension", does it means that you have a report and when you click on link which come from a dimension level, it doesn't work ?
Regards
Nico

Similar Messages

  • Illegal cross join within the same dimension caused by incorrect subject ar

    hi!
    Imagine the following BMM:
    There is one Logical Dimension Table "Service Account" with the following LTS:
    - LTS "D_SERVICE"
    - LTS "D_SERVICE_CLASS"
    - LTS "D_SERVICE_STATUS"
    This Logical Tabe "Service Account" joins (One-to-many) with several Fact Tables (other Logical Tables).
    In the Physical Layer the joins for the "Service Account" LTS are:
    - One-to-many between D_SERVICE_CLASS and D_SERVICE
    - One-to-many between D_SERVICE_STATUS and D_SERVICE
    The problem is that when I build a report in Answers using only the following columns of the Logical Table "Service Account":
    - Service Class Desc (which exists in the Logical Table "Service Account" and in the Physical Table D_SERVICE_CLASS)
    - Service Status Desc (which exists in the Logical Table "Service Account" and in the Physical Tabl D_SERVICE_STATUS)
    - MSISDN (which existis in the Logical Table "Service Account" and in the Phsyical Table D_SERVICE)
    the following error appears:
    Estado: HY000. Código: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14065] Illegal cross join within the same dimension caused by incorrect subject area setup: [ (select * from prd.D_SERVICE where SOURCE_SYS in ('ARBOR','PPB') and DW_SERV_ST_ID in (100000003,100000009)) as T1836, D_SERVICE_CLASS T1916] with [ D_SERVICE_STATUS T1948] (HY000)
    SQL emitido: SELECT "SERVICE ACCOUNT"."TLC MSISDN9" saw_0, "SERVICE ACCOUNT"."IWS Service Class Desc" saw_1, "SERVICE ACCOUNT"."TLC Service Status Desc" saw_2 FROM "VFPT - Upgrade Siebel" WHERE "SERVICE ACCOUNT"."TLC MSISDN9" = '917330340' ORDER BY saw_0, saw_1, saw_2
    Help, please!
    Thanks.

    Physically, only D_SERVICE is joined to the facts. Then D_SERVICE_CLASS is joined to D_SERVICE (one-to-many) and D_SERVICE_STATUS is joined also to D_SERVICE (one-to-many).
    In the BMM, there is only one Logical Dimension Table for those 3 physical tables. This Logical Dimension Table is called "Service Account" and has 3 LTS: D_SERVICE, D_SERVICE_CLASS, D_SERVICE_STATUS. The Logical Dimension Table has several logical columns that are associated to those 3 LTS: SERVICE_KEY, SERVICE_CLASS_KEY, SERVICE_STATUS_KEY, SERVICE_MSISDN, SERVICE_CLASS_DESC, SERVICE_STATUS_DESC.
    The Logical Dimension Table "Service Account" is then joined to a fact table (one-to-many).
    I didn't understand the suggestion about the 3 LTS... Aren't we doing that already? Can you explain it better, please?
    thanks.

  • Illegal cross join within the same dimension caused by incorrect subject.

    Hello Gurus,
    I am getting this error for one calculated column in OBIEE 11G
    Illegal cross join within the same dimension caused by incorrect subject area setup. *[ WC_PC_POSITION_D AS Dim_WC_PC_POSITION_D] with [ W_GL_ACCOUNT_D AS Dim_W_GL_ACCOUNT_D On Dim_W_GL_ACCOUNT_D.ROW_WID = Fact_WC_PC_BUDGET_DTLS_F.GL_ACCOUNT_WID, WC_PC_BUDGET_DTLS_F AS Fact_WC_PC_BUDGET_DTLS_F] (HY000)*
    the same column is calculated in OBIEE 10G and it's giving fine result.
    the way it's calculated in BMM is we are using 2 different logical table's column for deriving new column.
    is anyone having any idea?
    Thanking You..

    More Specially,
    Physical Layer:
    Dim:View1,View2,View3,View4
    Fact:View5
    all Views are PK joined in Phsical layer.
    So I need all columns in 3 Views and few column in View4.
    In BMM :
    Dim:View1,View2,View3
    Fact:View 5
    are joined and created LTS in View3 for LTS View4 and dropped few coulmns and mapped the columns.
    In reports,
    If I pull the columns from View3 which is came from view4 then getting the error.
    I hope does it make sense.
    Please help on this.

  • [nQSError: 14065] Illegal cross join within the same dimension

    Hey guys,
    I'm stumped. I have two dimension tables that are joined 1:N (there is NOT an M:N relationship between them) and I have them joined in the Physical Layer and the Business Model and Mapping Layer. The two tables are F4101 (the "1") and F4102 (the "N") in the 1:N relationship. F4102 then joins to a fact table, and F4101 joins to NOTHING else. So I don't believe I have a circular condition or a need for a bridge table. Both tables are published to the Presentation Layer for reporting.
    The error occurs in Answers when I want to do something as trivial as display the three primary key columns together from F4101: F4101.col1, F4101.col2, F4101.col3 (all three make up the PK). When I do that, the following error occurs:
    "nQSError: 14065] Illegal cross join within the same dimension caused by incorrect subject area setup: [ F4101 T28761] with [ F4102 T1805] "
    What I can't figure out is WHY the F4102 table is listed in this error. I didn't try to report on it at all. See the logical SQL below from my query:
    "SQL Issued: SELECT "Item Master (F4101)".IMITM saw_0, "Item Master (F4101)".IMLITM saw_1, "Item Master (F4101)".IMAITM saw_2 FROM "Sales Analysis" ORDER BY saw_0, saw_1, saw_2"
    As soon as I take out one of the three PK columns and add in another non-PK column from F4101, it works just fine. And reporting on each of the three PK columns individually works as well in Answers.
    Any ideas? I would greatly appreciate it.
    Thanks.

    Try this;
    1. In the logical layer, create one folder called F4101_F4102.
    2. Map both F4101 and F4102 as logical table sources in that folder.
    3. Join from the folder F4101_F4102 to the fact using a Logical (new complex join) join.
    Chris.

  • Getting Error : Illegal cross join within the same dimension

    Hi All,
    At database there are 4 tables - XLE_Entity_profiles (A) , XLE_ETB_profiles (B) ,XLE_Registration (C),XLE_Reg_Function(D) .
    Attribute info is as below -
    A.Le_name
    B.LRU_name
    C. Registraton name
    D. Function_code
    I have to model a single dimension which contains the attributes from these tables and dimension should also support queries which contains attributes from this dimension only without selecting any fact.
    For Exp - query is as below -
    Le_name,Le-Registraton name,Le_Function_code,LRU_name,LRU_Registraton name,LRU_Function_code
    To support such query , i created aliases of table XLE_Registration,XLE_Reg_Function.
    Aliases names are - XLE_Registration_LE (E),XLE_Registration_LRU (F),XLE_Reg_Function_LE (G).,XLE_Reg_Function_LRU (H)
    Attributes from aliases are as below -
    XLE_Registration_LE- Le-Registraton name
    XLE_Registration_LRU -LRU_Registraton name
    XLE_Reg_Function_LE - Le_Function_code
    XLE_Reg_Function_LRU - LRU_Function_code
    i have renamed the attributes For LE and LRU.
    The Physical layer diagram is as below
    A < B
    E F
    G H
    [A:B (1:M) , A:E(1:M), E:G(1:M),B:F(1:M),F:H(1:M)]
    At logical layer , i have created a dimension DIM-LE with below logical table sources -
    A ,B,E,F,G,H
    Using the properties of LTS B , i mapped B to A.
    Using the properties of LTS E , i mapped E to A.
    Using the properties of LTS F , i mapped F to B.
    Using the properties of LTS G , i mapped G to E.
    Using the properties of LTS H , i mapped H to F.
    Now when i run the query , i am getting the error -
    Query - Le_name,Le-Registraton name,Le_Function_code,LRU_name,LRU_Registraton name,LRU_Function_code
    +++Administrator:2a0000:2a0004:----2008/11/07 19:39:03
    Query Status: Query Failed: [nQSError: 14065|http://forums.oracle.com/forums/] Illegal cross join within the same dimension caused by incorrect subject area setup: [
    XLE_REGISTRATIONS T1218 On XLE_REGISTRATIONS_LRU.REGISTRATION_ID = XLE_REG_FUNCTIONS_LRU.REGISTRATION_ID,
    XLE_REG_FUNCTIONS T5737,
    XLE_ETB_PROFILES T900 On XLE_ETB_PROFILES.ESTABLISHMENT_ID = XLE_REGISTRATIONS_LRU.SOURCE_ID,
    XLE_ENTITY_PROFILES T836 On XLE_ENTITY_PROFILES.LEGAL_ENTITY_ID = XLE_ETB_PROFILES.LEGAL_ENTITY_ID] with [
    XLE_REGISTRATIONS T1155 On XLE_REGISTRATIONS_LE.REGISTRATION_ID = XLE_REG_FUNCTIONS_LE.REGISTRATION_ID,
    XLE_REG_FUNCTIONS T5703,
    XLE_ENTITY_PROFILES T836 On XLE_ENTITY_PROFILES.LEGAL_ENTITY_ID = XLE_REGISTRATIONS_LE.SOURCE_ID]
    But when i run below query,which resembles the BI Answer query, against the database ,
    select distinct A.NAME as c1,
    B.REGISTERED_NAME as c2,
    E.Function_code as c5,
    C.NAME as c3,
    D.REGISTERED_NAME as c4,
    F.Function_code as c6
    from
    XLE_ENTITY_PROFILES A,
    XLE_REGISTRATIONS B,
    XLE_REG_FUNCTIONS E,
    XLE_ETB_PROFILES C,
    XLE_REGISTRATIONS D,
    XLE_REG_FUNCTIONS F
    where (A.LEGAL_ENTITY_ID = C.LEGAL_ENTITY_ID and
    A.LEGAL_ENTITY_ID = B.SOURCE_ID and
    C.ESTABLISHMENT_ID = D.SOURCE_ID and
    B.SOURCE_TABLE = 'XLE_ENTITY_PROFILES' and
    D.SOURCE_TABLE = 'XLE_ETB_PROFILES' and
    E.Registration_id = B.Registration_id and
    F.Registration_id = D.Registration_id)
    order by c1, c2,c5, c3, c4,c6
    i don't get any error.
    Please let me know , why am i getting this error and how can i resolve this issue?

    Hi All,
    Is there any update on this ?
    Thanks,Ashish

  • Illegal cross join within the same dimension

    Hi,
    When certain fields are selected within the presentation table an "illegal cross join" error is returned by the BI Server. However if a FACT is added from one of the other presentation tables the "illegal cross join" error goes away. we need to query without fact column.
    We are getting following error
    State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14065] Illegal cross join within the same dimension caused by incorrect subject area setup: [ CALL_CENTER.COUNSELOR_MANAGER T782130] with [ CALL_CENTER.COUNSELOR_HR T781594 On CALL_CENTER.COUNSELOR_HR.MASTER_STAFF_COUNSELOR_ID = CALL_CENTER.MASTER_STAFF_COUNSELOR.MASTER_STAFF_COUNSELOR_ID, CALL_CENTER.MASTER_STAFF_COUNSELOR T781739] (HY000)
    Can anybody help me solving this issue.
    Thanks,
    KS.

    Please give us an example of what you need.
    OBIEE perform a query in the dimension or through the fact table.
    You can't join two dimensions in the repository without going through a fact table.
    If you need to query without fact column, it's because you have design two dimensions where
    normally you can do one.
    You have then two solutions :
    * change the design of your logical model to make only one dimension.
    * use the OBIEE logical SQL in answer.
    http://gerardnico.com/wiki/dat/obiee/bi_server/design/obiee_logical_sql
    Success
    Nico

  • [nQSError: 14065] Illegal cross join

    I am getting the following the following error “[nQSError: 14065] Illegal cross join” in the following situation.
    We have one dimension table Called “WC_CUSTOMER_D” and in that table we are storing 2 row_wids one to store the “Status Wid” (data comes from WC_LOV_D) and “Risk Wid” (again data comes from WC_LOV_D) of the customer . We have 2 alias table as Dim_Status_WC_LOV_D and Dim_Risk_WC_LOV_D and it joins to the Dim_WC_CUSTOMER_D .
    In Logical we have one Logical table “Dim Customer” and has 3 Logical table source (reason is we can write content level filters ) for the each dimension tables. We exposed some attributes from the Dim_WC_CUSTOMER_D, Dim_status_WC_LOV_D and Dim_Risk_WC_LOV_D tables.
    In answer , We are getting the illegal cross join error when we expose fields from 2 WC_LOV_D alias tables
    Error comes only if we use alias of same physical type more than once
    Query Status: Query Failed: [nQSError: 14065] Illegal cross join within the same dimension caused by incorrect subject area setup: [
    WC_CUSTOMER_D T624599,
    WC_LOV_D T624699] with [
    WC_LOV_D T628734]
    But when I add a fact , BI is able to build a query
    select T624599.SOURCE_SYSTEM as c1,
    T624699.LOOKUP_CODE as c2,
    T628734.LOOKUP_CODE as c3,
    count(distinct T623979.CUST_ACCT_WID) as c4
    from
    WC_LOV_D T628734 /* Dim_Risk_WC_LOV_D_ */ ,
    WC_LOV_D T624699 /* Dim_Staus_WC_LOV_D */ ,
    WC_CUSTOMER_D T624599 /* Dim_W_CUSTOMER_D */ ,
    WC_CUSTOMER_F T623979 /* Fact_WC_CUSTOMER_F */
    where ( T623979.CUST_FIN_PROFL_WID = T624599.ROW_WID and T624599.X_ACCOUNT_STATUS_WID = T624699.ROW_WID and T624599.X_RISK_CODE_WID = T628734.ROW_WID and T628734.LOOKUP_TYPE = 'RISK' and T624699.LOOKUP_TYPE = 'STATUS' )
    group by T624599.X_ SOURCE_SYSTEM, T628734.LOOKUP_CODE, T624699.LOOKUP_CODE
    order by c1, c2, c3
    Please guide me if I did some mistake or any work around for this issue.
    Thanks
    Barna

    Hi,
    Maybe you have already resolved this issue. In any case, I found a solution following instructions in support note ID 1329237.1.
    Best regards,
    Cristina

  • How to resolve illegal cross join error

    Can someone please tell me how can we avoid illegal cross join error in modeling? If someone has any reference document , please share it.
    I have 5 tables - Dim (A, B , C,E) and Fact( D). C is lookup table which is used to resolve the lookup code column in table E.
    The relationships between these are
    A--< B--< E >--C
    & A--<D
    My requirement is i have to expose Attributes of A,B ,C & E within Dimension.
    These attributes (from B,C,E) will be treated as property of A.
    Someone may query these attributes without selecting any column from fact table.
    Thanks & Regards,
    Ashish

    Hi Ashish,
    it's not the first time you come up with this kind of question and I'm wondering if you understand the principle of granularity when I read your questions.
    On physical level, a fact table must always join with the lowest level of detail of your dimension table. Let me explain, by giving an example which looks like your situation.
    Assume I have three tables:
    Table "E" contains products, which has attributes like: product_id and product_name
    Table "B" contains order line items, which has attributes like: order_line_item_id, order_id and product_id.
    Table "A" contains orders, which has attributes like: order_id and customer_name.
    Table "D" contains facts ("metrical data") about my order: which has attributes like: order_id, order_revenue.
    This will be the diagram on physical level: E--<B--<A--<D
    Here are my joins: E.product_id on B.produc_id, B.order_id on A.order_id, A.order_id--<D.order_id
    Now, my question to you is: will I be able to get the revenue of a certain product?
    The answer is: No, because I don't know what part of my order is spent on a certain product. The problem is thus that the data in the fact table isn't stored on that level of detail, or in other words the fact and dimension table don't share the same level of granularity.
    How it should be:
    If you want to get the revenue per product, you will need to have a second fact table "G", which has data which is stored on order line item level. This table contains the following attributes: order_line_item_id, product_id and order_line_item_revenue.
    This will become your diagram on physical level:
    B--<G>--E
    Joins: B.order_line_item_id on G.order_line_item_id and E.product_id on G.product_id
    Table E has become a dimension of fact table G.
    The first physical diagram should look like this:
    A--<D
    If you want you can model both physical diagrams into one logical diagram, assuming that A and D (order dimension and fact table) are aggregates of B and G (order line items dimension and fact table). In that case you should read this blog item: http://obiee101.blogspot.com/2008/11/obiee-making-it-aggregate-aware.html
    Regards,
    Stijn

  • SO idoc from PO idoc within the same client

    Hello SAP Gurus,
    We need help with the following .
    The requirement is we need to create the Sales order from Purchase order using idocs within the same client .
    We created the partner profile of the customer and the vendor .
    Customer ---maintained an inbound parameters with message type ORDERS and process code ORDE
    Vendor -
    maintained outbound parameters with message type ORDERS and idoc type ORDERS05 and process code ME10 .
    Now when we create the PO and check the status in WE02 we get the error status 56 , EDI: Partner profile inbound not available.
    What could be the posible cause of the error .
    Anybody with some suggestions and solutions .
    Thanks
    Honey

    Hi ,
    You should maintain in the inbound parameters  and out bound parameters also
    out bound parametrs
    message typ[e---ORDERS
    receiver port----
    basic type -
    ORDERS05
    tick on transfer idoc immediately
    Inbound parameters
    message type ---ORDERS
    process code --ORDE
    if you have any further clarifications let me know
    Regards
    Damu

  • Why is the Star Transformation using two indexes for the same dimension?

    Hi,
    Recently, I have made an investigation about the Star Transformation feature. I have found a strange test case, which plays an important role in my strategy for our overall DWH architecture. Here it is:
    The Strategy:
    I would like to have the classical Star Transformation approach (single column Bitmap Indexes for each dimension foreign key column in the fact table), together with additional Bitmap Join Indexes for some of the dimension attributes, which would benefit from the materialization of the join (bitmap merge operation will be skipped/optimized).
    The query:
    select dp.brand, ds. region_name, dc.region_name
         , count(*), sum(f.extended_price)
      from fact_line_item  f
         , dim_part       dp
         , dim_supplier   ds
         , dim_customer   dc
    where dp.mfgr        = 10                 -- dimension selectivity = 1/10 --> acttual/fact selectivity = 6/10
       and f.part_dk      = dp.dk
       and ds.region_name = 'REGION #1' -- dimension selectivity = 1/9
       and f.supplier_dk  = ds.dk
       and dc.region_name = 'REGION #1' -- dimension selectivity = 1/11
       and f.customer_dk  = dc.dk
    group by dp.brand, ds. region_name, dc.region_name
    The actual plan:
    | Id  | Operation                              | Name                        | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers | Reads  |
    |   0 | SELECT STATEMENT                       |                             |      1 |        |  3247 (100)|      1 |00:01:42.05 |     264K|    220K|
    |   1 |  HASH GROUP BY                         |                             |      1 |      2 |  3247   (1)|      1 |00:01:42.05 |     264K|    220K|
    |*  2 |   HASH JOIN                            |                             |      1 |  33242 |  3037   (1)|    217K|00:01:29.67 |     264K|    220K|
    |*  3 |    TABLE ACCESS FULL                   | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      4 |
    |*  4 |    HASH JOIN                           |                             |      1 |  33245 |  2934   (1)|    217K|00:01:29.10 |     264K|    220K|
    |*  5 |     TABLE ACCESS FULL                  | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.08 |     316 |      8 |
    |*  6 |     HASH JOIN                          |                             |      1 |  33248 |  2831   (1)|    217K|00:01:28.57 |     264K|    220K|
    |*  7 |      TABLE ACCESS FULL                 | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
    |   8 |      PARTITION RANGE ALL               |                             |      1 |  36211 |  2827   (1)|    217K|00:01:28.01 |     264K|    220K|
    |   9 |       TABLE ACCESS BY LOCAL INDEX ROWID| FACT_LINE_ITEM              |      6 |  36211 |  2827   (1)|    217K|00:01:33.85 |     264K|    220K|
    |  10 |        BITMAP CONVERSION TO ROWIDS     |                             |      6 |        |            |    217K|00:00:07.09 |   46980 |   3292 |
    |  11 |         BITMAP AND                     |                             |      6 |        |            |     69 |00:00:08.33 |   46980 |   3292 |
    |  12 |          BITMAP MERGE                  |                             |      6 |        |            |    193 |00:00:02.09 |    2408 |   1795 |
    |  13 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   4330 |00:00:04.66 |    2408 |   1795 |
    |  14 |            BUFFER SORT                 |                             |      6 |        |            |     60 |00:00:00.01 |       6 |      0 |
    |* 15 |             TABLE ACCESS FULL          | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
    |* 16 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_PART_DIM_KEY_BIX |     60 |        |            |   4330 |00:00:02.11 |    2402 |   1795 |
    |* 17 |          BITMAP INDEX SINGLE VALUE     | FACT_LI__P_PART_MFGR_BJX    |      6 |        |            |   1747 |00:00:06.65 |     890 |    888 |
    |  18 |          BITMAP MERGE                  |                             |      6 |        |            |    169 |00:00:02.78 |   16695 |    237 |
    |  19 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   5460 |00:00:01.56 |   16695 |    237 |
    |  20 |            BUFFER SORT                 |                             |      6 |        |            |   5460 |00:00:00.02 |     316 |      0 |
    |* 21 |             TABLE ACCESS FULL          | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     316 |      0 |
    |* 22 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_CUST_DIM_KEY_BIX |   5460 |        |            |   5460 |00:00:02.07 |   16379 |    237 |
    |  23 |          BITMAP MERGE                  |                             |      6 |        |            |    170 |00:00:03.65 |   26987 |    372 |
    |  24 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   6672 |00:00:02.23 |   26987 |    372 |
    |  25 |            BUFFER SORT                 |                             |      6 |        |            |   6672 |00:00:00.01 |     316 |      0 |
    |* 26 |             TABLE ACCESS FULL          | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      0 |
    |* 27 |            BITMAP INDEX RANGE SCAN     | FACT_LI__S_SUPP_DIM_KEY_BIX |   6672 |        |            |   6672 |00:00:02.74 |   26671 |    372 |
    The Question:
    Why is the Star Transformation using both indexes FACT_LI__P_PART_DIM_KEY_BIX and FACT_LI__P_PART_MFGR_BJX for the same dimension criteria (dp.mfgr = 10)?? The introduction of the additional Bitmap Join Index actually make Oracle to do the work twice !!!
    Anybody, any idea ?!?

    Dom, here it is the plan with the predicates:
    | Id  | Operation                              | Name                        | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers | Reads  |
    |   0 | SELECT STATEMENT                       |                             |      1 |        |  3638 (100)|      1 |00:06:41.17 |     445K|    236K|
    |   1 |  HASH GROUP BY                         |                             |      1 |      2 |  3638   (1)|      1 |00:06:41.17 |     445K|    236K|
    |*  2 |   HASH JOIN                            |                             |      1 |  33242 |  3429   (1)|    217K|00:08:18.02 |     445K|    236K|
    |*  3 |    TABLE ACCESS FULL                   | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.03 |     319 |    313 |
    |*  4 |    HASH JOIN                           |                             |      1 |  33245 |  3326   (1)|    217K|00:08:17.47 |     445K|    236K|
    |*  5 |     TABLE ACCESS FULL                  | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     319 |    313 |
    |*  6 |     HASH JOIN                          |                             |      1 |  33248 |  3223   (1)|    217K|00:08:16.63 |     445K|    236K|
    |*  7 |      TABLE ACCESS FULL                 | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
    |   8 |      PARTITION RANGE ALL               |                             |      1 |  36211 |  3219   (1)|    217K|00:08:16.30 |     445K|    236K|
    |   9 |       TABLE ACCESS BY LOCAL INDEX ROWID| FACT_LINE_ITEM              |      6 |  36211 |  3219   (1)|    217K|00:08:40.89 |     445K|    236K|
    |  10 |        BITMAP CONVERSION TO ROWIDS     |                             |      6 |        |            |    217K|00:00:32.00 |   46919 |  19331 |
    |  11 |         BITMAP AND                     |                             |      6 |        |            |     69 |00:00:34.50 |   46919 |  19331 |
    |  12 |          BITMAP MERGE                  |                             |      6 |        |            |    193 |00:00:00.58 |    2353 |      1 |
    |  13 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   4330 |00:00:00.10 |    2353 |      1 |
    |  14 |            BUFFER SORT                 |                             |      6 |        |            |     60 |00:00:00.01 |       6 |      0 |
    |* 15 |             TABLE ACCESS FULL          | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
    |* 16 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_PART_DIM_KEY_BIX |     60 |        |            |   4330 |00:00:00.07 |    2347 |      1 |
    |* 17 |          BITMAP INDEX SINGLE VALUE     | FACT_LI__P_PART_MFGR_BJX    |      6 |        |            |   1747 |00:01:23.64 |     882 |    565 |
    |  18 |          BITMAP MERGE                  |                             |      6 |        |            |    169 |00:00:09.14 |   16697 |   7628 |
    |  19 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   5460 |00:00:02.19 |   16697 |   7628 |
    |  20 |            BUFFER SORT                 |                             |      6 |        |            |   5460 |00:00:00.01 |     316 |      0 |
    |* 21 |             TABLE ACCESS FULL          | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     316 |      0 |
    |* 22 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_CUST_DIM_KEY_BIX |   5460 |        |            |   5460 |00:00:08.78 |   16381 |   7628 |
    |  23 |          BITMAP MERGE                  |                             |      6 |        |            |    170 |00:00:21.46 |   26987 |  11137 |
    |  24 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   6672 |00:00:10.29 |   26987 |  11137 |
    |  25 |            BUFFER SORT                 |                             |      6 |        |            |   6672 |00:00:00.01 |     316 |      0 |
    |* 26 |             TABLE ACCESS FULL          | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      0 |
    |* 27 |            BITMAP INDEX RANGE SCAN     | FACT_LI__S_SUPP_DIM_KEY_BIX |   6672 |        |            |   6672 |00:00:20.94 |   26671 |  11137 |
    Predicate Information (identified by operation id):                                                                                                  
       2 - access("F"."SUPPLIER_DK"="DS"."DK")                                                                                                           
       3 - filter("DS"."REGION_NAME"='REGION #1')                                                                                                        
       4 - access("F"."CUSTOMER_DK"="DC"."DK")                                                                                                           
       5 - filter("DC"."REGION_NAME"='REGION #1')                                                                                                        
       6 - access("F"."PART_DK"="DP"."DK")                                                                                                               
       7 - filter("DP"."MFGR"=10)                                                                                                                        
      15 - filter("DP"."MFGR"=10)                                                                                                                        
      16 - access("F"."PART_DK"="DP"."DK")                                                                                                               
      17 - access("F"."SYS_NC00017$"=10)                                                                                                                 
      21 - filter("DC"."REGION_NAME"='REGION #1')                                                                                                        
      22 - access("F"."CUSTOMER_DK"="DC"."DK")                                                                                                           
      26 - filter("DS"."REGION_NAME"='REGION #1')                                                                                                        
      27 - access("F"."SUPPLIER_DK"="DS"."DK")                                                                                                           
    Note                                                                                                                                                 
       - star transformation used for this statement                                                                                                     

  • Runtime prompts with the same dimension

    Hello,
    I'm setting up a business rule to contain two variables referring to members in the same dimension (for example, Account_VAR and Account_Basis_VAR both using Member of the Account dimension). I would like to have Account_VAR default as filled based on the selected member on the form (and hidden) and then have Account_Basis_VAR default to the same account as Account_VAR, but selectable based on which accounts the user has Read access to.
    The calculation is working properly and the values are being distributed to the Account selected (Account_VAR) based on the current allocation to level 0 in the base account(Account_Basis_VAR), but I would like to hide Account_VAR while still prompting for Account_Basis_VAR. I've tried a few iterations of settings but both account prompts always appear in the runtime prompt window.
    Is there a workaround for this?
    Nik

    The strange thing is that the results from the queries are correct running them in SQL Developer. This is one that works:
    SELECT Project.Project saw_0, "- SalesOrderFact"."Sales Amount" saw_1, "- PurchaseOrderFact"."Purchase Amount" saw_2, REPORT_SUM(saw_1 BY ), REPORT_SUM(saw_2 BY ) FROM SalesOrder ORDER BY saw_0
    SALES ORDER:
    select T3032.PROJECT_DESCRIPTION as c1,
    sum(T161.SALES_AMOUNT_LOCAL) as c2
    from
    DIM_PROJECT_V T3032,
    CUBE_SALES_ORDER T161
    where ( T161.DIM_PROJECT = T3032.DIMENSION_KEY )
    group by T3032.PROJECT_DESCRIPTION
    order by c1
    PURCHASE_ORDER:
    select T3032.PROJECT_DESCRIPTION as c1,
    sum(T3020.TOTAL_BUY_AMOUNT) as c2
    from
    DIM_PROJECT_V T3032,
    CUBE_PURCH_ORDER T3020
    where ( T3020.DIM_PROJECT = T3032.DIMENSION_KEY )
    group by T3032.PROJECT_DESCRIPTION
    order by c1
    And this will give the wrong result in Answers (correct in SQL..):
    SELECT Project."Project Id" saw_0, "- SalesOrderFact"."Sales Amount" saw_1, "- PurchaseOrderFact"."Purchase Amount" saw_2, REPORT_SUM(saw_1 BY ), REPORT_SUM(saw_2 BY ) FROM SalesOrder ORDER BY saw_0
    SALES_ORDER:
    select T3032.PROJECT_KEY_NAME_ID as c1,
    sum(T161.SALES_AMOUNT_LOCAL) as c2
    from
    DIM_PROJECT_V T3032,
    CUBE_SALES_ORDER T161
    where ( T161.DIM_PROJECT = T3032.DIMENSION_KEY )
    group by T3032.PROJECT_KEY_NAME_ID
    order by c1
    PURCHASE_ORDER:
    select T3032.PROJECT_KEY_NAME_ID as c1,
    sum(T3020.TOTAL_BUY_AMOUNT) as c2
    from
    DIM_PROJECT_V T3032,
    CUBE_PURCH_ORDER T3020
    where ( T3020.DIM_PROJECT = T3032.DIMENSION_KEY )
    group by T3032.PROJECT_KEY_NAME_ID
    order by c1
    As you can see the SQL look very familiar, and I cannot see anything in SQL that should be the cause of this error. I think the error must be in the BI Memory or something.
    Any ideas?

  • How to use multiple profiles within the same instance of Thunderbird

    About a month ago, I had Thunderbird configured with three profiles,
    and all three could be used within a single startup/instance of
    Thunderbird. That PC is now gone. I have re-configured the three
    profiles on a new PC, but am having trouble making all three
    useable within the same instance of Thunderbird. Can you help?
    Both PCs are/were Windows-7 64 bit.

    Thunderbird only opens on the default if one profile
    or
    if Profile Manager is instructed to ask at startup it will allow you to choose which Profile to open else it opens on the last Profile used..
    So it shows one Profile at a time in one instance of Thunderbird.
    However, one Profile can have many mail accounts.
    eg: I run 4 mail accounts in one Profile.

  • SSO for various applications within the same portal

    Is it possible to implement SSO at the application level in an EP 7.0 environment?
    Ex:  One Portal with ESS and BI Functionality (BI is connected to the BI backend, ESS is connected to the ECC backend, but all of it exists within the same portal instance) in which the BI Explorer would rely on SSO, while the ESS would require a logon to the portal.  The initial page of the portal would not be a logon screen, but rather a menu screen
    Does this functionality exist?

    For our purposes, ESS would have to be authenticated (perferably through Active Directory), while BI Explorer wouldn't require "visible" authentication, BUT the question would be, could all of this exist on the same portal..
    I agree that it certainly wouldn't be user friendly to ask users to logon (using AD l/p) for certain parts but not others.  I think the solution would simply to have 2 portal instances (ESS/ECC = Logon/Password,  BI Portal = SSO), and to federate the BI to the ECC Portal. That way, if someone wanted to work in BI and only BI, they could go without logging on, but if they wanted to go to the ESS Portal they would have to logon BUT would be able to use both ESS and BI.
    This all stems from an effort to eliminate the neccessity of having to logon to a portal (for a small group of managers), but still maintaining a level of security for ALL users in regards to employee self-service

  • Simple button action that goes to a page within the same doc

    I can't figure this out. I have a button I want to use that takes a person back to the first, or second page of the same doc. It's a catalog section with a table of contents. I need to make links for the pdf that takes people to certain pages within the same document.
    In the Buttons panel, I see how to make the button, but when I assign an action, the only choice that makes sense is "Go To Destination", but I don't get or see any way to choose "page 2" of the document, or another selection method.
    I did this before a few years ago on hundreds of pages, and when I open those old documents up to copy/paste the same buttons, they don't even appear to have actions on them anymore, as if it never happened.
    So, what's the secret? Certainly there's a way to link to another page in the same ID file, no?

    Finally figured it out. I do NOT use the button panel at all. No buttons needed. Just select the grouped object that I want for my button, and hit the "add hyperlink" button in the Hyperlink panel. Then choose "Page" from the menu that opens up and be on my way. What was throwing me for a bad loop, was that I had copied and pasted the button graphic form another document. Well, since the link made previously was broken now, I had the red flag in the Hyperlinks panel...and thus, the "new hyperlink" button was greyed out, sending me in circles. The minute I deleted the old hyperlink it carried over from the old document, the new hyperlink button worked again and all was well.
    Thanks.

  • I subscribed to iTunes Match and would like to sync my music on multiples devices that have different Apple IDs within the same iCloud family.

    I subscribed to iTunes Match and would like to sync my music on multiples devices that have different Apple IDs within the same iCloud family.
    Can someone indicate the way to proceed?
    Thanks.

    Hi,
    You can't use family sharing or multiple Apple IDs with iTunes match.
    ITunes match is only attached to Apple id that you used to subscribe.
    Jim

Maybe you are looking for