Querying Levels in Dimensions joined to the Facts

I created a location dimension using the standard levels, i.e., region > subregion > country > state > location_id. I then attached it to a sales fact that had the location_id as the key, but when I tried to query the cube by it's levels the only level I see is the location_id level which is at the state. None of the other levels appear or are queryable when I do something like:
SELECT * FROM vw_SALES_CUBE A, vw_LOCATION_DIM B
WHERE A.LOCATION_DIM = B.DIM_KEY
AND A.LEVEL = 'COUNTRY'
Only one level comes up although in the location_dim all the other levels exist the join does not carry them over. The data for the levels appears in the COUNTRY_LONG_DESCRIP column and not in the LEVEL column.
What am I doing wrong. Are there other objects I need to create like an MV.
jrod

I was thinking that is if I created a cube such as the one described in the thread and that I did a query along the LEVEL_NAME that the cube would fetch the data without the need for me to create say MV's aggregateing the data. For example,
/* The following is a basic query against a fact table */
SELECT T.CALENDAR_YEAR_DSC TIME, SUM(F.SALES) SALES
FROM TIME_DIM T, UNITS_FACT F
WHERE T.CALENDAR_YEAR_DSC IN ('2005', '2006')
AND T.MONTH_ID = F.MONTH_ID
GROUP BY T.CALENDAR_YEAR_DSC;
/* The next query fetches the exact same results from a cube using filters: */
SELECT T.LONG_DESCRIPTION TIME, F.SALES SALES
FROM TIME_CALENDAR_VIEW T,
PRODUCT_PRIMARY_VIEW P,
CUSTOMER_SHIPMENTS_VIEW CU,
CHANNEL_PRIMARY_VIEW CH,
UNITS_CUBE_VIEW F
/* Apply filters to every dimension */
WHERE T.LONG_DESCRIPTION IN ('2005', '2006')
AND P.LEVEL_NAME = 'TOTAL'
AND CU.LEVEL_NAME = 'TOTAL'
AND CH.LEVEL_NAME = 'TOTAL'
/* Join dimension views to cube view */
AND T.DIM_KEY = F.TIME
AND P.DIM_KEY = F.PRODUCT
AND CU.DIM_KEY = F.CUSTOMER
AND CH.DIM_KEY = F.CHANNEL
ORDER BY TIME;
In these two queries I fetch the same grain. So why is it that the cube has not precomputed these factors. What do I need to do this?

Similar Messages

  • Not exists / union - two dimensions nothing in the fact folder, possible???

    What I am trying to do is (in functional terms) produce an invoices on hold report.
    This has two distinct characteristics - some invoices are coding but on hold (easy - see first part of the SQL below), but some invoices have no coding, nothing in the FACT folder and I need to show two dimension folders which currently only join via the FACT folder - is this possible??
    equivalent SQL =>
    select supp.supplier_name, inv.invoice_number, inv.invoice_amount, dis.amount, code.segment1||'/||code.segment2
    from     AP_INVOICES_MV inv
    ,          ap_suppliers_mv supp
    ,       ap_holds_mv hold
    ,      AP_INVOICE_DISTRIBUTIONS dis
    ,     gl_coding code
    where inv.invoice_key = hold.invoice_key
    and    inv.supplier_key = supp.supplier_key
    and  inv.invoice_id = dis.invoice_id
    and   dis.code_key = code.code_key
    and   hold.holds <> 'No Holds'
    union
    select supp.supplier_name, inv.invoice_number, inv.invoice_amount, 0 amount, 'XXXXX/XXXX' gl_code
    from     AP_INVOICES_MV inv
    ,          ap_suppliers_mv supp
    ,       ap_holds_mv hold
    where inv.invoice_key = hold.invoice_key
    and    inv.supplier_key = supp.supplier_key
    and   hold.holds <> 'No Holds'
    and   not exists
    (select 'x'
    from    ap_invoice_distributions dis
    where dis.invoice_id = inv.invoice_id)
    order by 1, 2, 4 ascMy problems are; -
    1. is that the second part of the union (not exists section) requires me to join two DIMENSION tables without going via the FACT table is this possible?? (If so how - what JOINS would I need on between the FACT and the DIMENSIONS and would this significantly impede running speed generally)
    2. Given that even when writing direct database requests the FROM part of the SQL is the subject area, not the tables, the tool writes the joins for you, how can I write the equivalent of the above??
    n.b.
    AP_INVOICES_MV - DIMENSION
    ap_suppliers_mv - DIMENSION
    ap_holds_mv - DIMENSION
    gl_coding code - DIMENSION
    AP_INVOICE_DISTRIBUTIONS FACT
    With the structure following the classic STAR with all folders described in the dimensions equi joining to the FACT folder, BUT some in the invoices dimension will not have corresponding values in the FACT folder (un-coded invoices).
    With thanks for your input,
    Robert.

    Try this app: http://tyorex.com/iWorkConverter
    Batch convert Pages files to doc and pdf.

  • Two Filter on Two dimensions without constraining the fact table

    Hi All,
    does anybody know how to avoid the fact constraint when creating a report with two filters on different dimensions?
    I have a big fact table with more than 10 Million rows. In the starmodel the is the dimension customer and products. I create a filter on the customer atrribute "Status" and choose the value "Active". Now I add the column "Product Type" from the dimension "Product" to the filter section. When I want to choose a value OBIEE executes a select statement within the fact table. So I have to wait very long to select a value. Is there any way to say OBIEE only to select the dimension table without joining the fact table?
    Thank you very much in Advance.
    Regards,
    Stefan

    Hi Stefan,
    Generally queries on the dimensions (across dimesions also) always go through a fact. In case, you would like the queries not be through fact table, but just the dimension tables right away, you can set up a separate subject area for them.
    You can create a separate subject area based on a dummy fact table to get these prompt values.
    Please refer to http://gerardnico.com/wiki/dat/obiee/presentation_service/obiee_parameter_prompt_subject_area for more details on this setup.
    Hope this helps.
    Thank you,
    Dhar

  • Physical query generation: unneeded dimension tables get joined to the fact

    Hi there!
    The setup is the following:
    There is a logical fact table which is joined to 7 logical dimensions, it has 4 table sources which correspond to different time dimension levels (all other dimensions are mapped to Detail level).
    Time dimension logical table also has 4 different table sources (for days, months, quarters, and years).
    The data source is an Oracle Database 11gR2.
    The problem is:
    No matter what the logical query is, in the physical query all 7 joins are performed, even if the resulting data is then simply discarded. This results in very bad query performance.
    I feel that it is somehow related to the level-based fragmentation (since, for instance, inclusion of time dimension columns in SELECT list (not in WHERE) seems to affect physical queries), but lack sufficient knowledge to solve this problem or put up with it.
    My questions are the following:
    1) Have you ever encountered such a situation?
    2) Can unneeded joins be eliminated?
    2.1) If yes, how?
    2.2) If not, then why are they needed?
    Thanks in advance!

    Physical level:
    D01-D06 - ordinary physical tables.
    D_DATES - all time levels from dates to years, D_MONTHS - time levels from months to years, also D_QUARTERS and D_YEARS.
    F_DAILY - fact table joined to all of the D01-D06 and to D_DATES, F_MONTHLY - joined to D01-D06 and D_MONTHS, also F_QUARTERLY and F_YEARLY. All measure columns are the same.
    Logical level:
    D01-D06 correspond to ordinary logical tables with a single table source. Logical dimensions are created.
    D_TIME is a logical time dimension with four levels (dates, months, quarters, and years) and four table sources ( D_DATES, D_MONTHS, D_QUARTERS, and D_YEARS ).
    F is a fact table with four logical table sources ( F_DAILY, F_MONTHLY, F_QUARTERLY, and F_YEARLY ) with aggregation content levels set correspondingly.
    OBIEE correctly picks physical table sources for different time levels, but generates extremely inefficient SQL (joining all dimension sources in a WITH-subquery, doing ROW_NUMBER over a result set, and then discarding half the columns, which were not needed to start with).

  • Mapping the Fact table to different levels of a dimension

    Hi,
    I have a fact table which stores the data for 4 levels of the dimensions. The aggregation method was taken care by PL/SQL and the fact table will have the data for all the 4 levels. When im trying to map all the levels to a column in the fact table using the OEM, it is generating the F KEY constraints referncing the columns mapped for the various levels of the dimension.
    The problem is that im using a denormalised table for maintaing the values of the dimension. So the columns mapped for the levels(Except for the lowest) can't have the unique key defined on it. The cube is not getting created because of the error in creating the F KEY.
    Can u please suggest how to map this fact table.
    Thnks,
    Manohar Vanama

    I am not exactly clear on your schema but I believe you are trying to map tables which are not strict star or snowflake. This means that you cannot use CWM1 (and OEM), unless you change the structure of the tables. You might be able to map the tables with CWM2. The document below will assist you:
    Oracle9i OLAP User's Guide
    Chapter 4. Designing Your Database for OLAP
    Chapter 5. Creating OLAP Catalog Metadata

  • Essbase answers - None of the fact tables are compatible with the query request "member"

    Hi,
    I have modelled an Essbase database into the repository.
    If I pull the measure, period and year dimension in and filter on the year (member) and display the year (member) along with the period (alias) and measure it errors with =>
    State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 14020] None of the fact tables are compatible with the query request Fiscal Year.Fiscal Year Code. (HY000)
    However, all other things being equal if I change the year displayed to the alias then it works.
    Anyone tell me why??
    Is there a limitation that Essbase brings through that you cannot view what you filter on?
    thanks,
    Robert.

    Hi
    i have done the content level setting in each of the table, D1,F1 and F2(LTS), now i am getting the following error..
    State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table Gl Sets Of Books) does not contain mapping for [Code Combinations.Code Combinations.Affiliate, GL Balances.GL Balances.Currency Code, GL Balances.GL Balances.PTD_Balance, Gl Sets Of Books.Gl Sets Of Books .SoB Name]. (HY000)
    Gl Balances : D1
    Code Commbination: F1
    Gl Sets Of Books : F2
    I have checked the joins in physical and BMM layer..all are fine..

  • Logical Dimension tabel does not join to any fact source

    I want to create a new “Dimension” table. This will be an Account Geographic dimension. My Business and Physical model are setup as follows:
    1.     Account Address (WC_ADDR_F) is joined to Account (W_ORG_D) which is joined to multiple Fact tables (Ex: Order Item (W_ORDERITEM_F)
    2.     When I perform “Global Consistency” check it comes back with no errors or warnings.
    I create the Account Geographic dimension as follows:
    1.     I right click on the subject area and select New Object->Dimension and name it “Account Geographic Dimension”. I do not select or change anything else.
    2.     I right click on the new dimension and select New Object->Logical Level. I name the level “All” and check the “Grand total level” check box. Nothing else is changed.
    3.     I right click on the “All” level and select New Object->Child Level. I name the level “Country”, set number of elements to 200.
    4.     I right click on the “Country” level and select New Object->Child Level. I name the level “State”, set number of elements to 250.
    5.     I drag the “Country” element from the Logical table (Account Address) to the “Country Level” on the new Dimension (Account Geographic Dimension)
    6.     I drag the “State” element from the Logical table (Account Address) to the “State Level” on the new Dimension (Account Geographic Dimension)
    7.     I then select the “Country” level properties and add a new key. For the key I select the “Country” column that I just dragged up there.
    8.     I then select the “State” level properties and add a new key. For the key I select the “State” column that I just dragged up there.
    My goal is that when an Analyst selects the “Country” column in Answers from the “Account Address” area that the user would be able to drill down from “Country” to “State”.
    When I perform “Global Consistency” I now get the following warning:
    WARNINGS:
    BUSINESS MODEL CCCi Analytics:
    [39008] Logical dimension table Account Address has a source CCCi_Dim_WC_ADDR_F_AccountAddress that does not join to any fact source.
    Why do I now get an error no the Account Address table for not connecting to a Fact table? The error message references the “Account Address” dimension table which I believe is the source to the Account Geographic Dimension. If this is the source table, why did it not get a warning message before I created the new dimension?
    Thanks…

    Here is the solution that I was able to get to work:
    1.     I did not have to reduce the business model to a star but was able to keep it a snowflake
    Final design (which was same as the original) here is the Business Model (snowflake schema)
    1.     Account Hierarchy (logical) -> Account (logical) -> Order Item Fact
    2.     Account Address (logical) -> Account (logical) -> Order Item Fact
    In this model the logical tables Account Hierarchy and Account Address snowflake off of the Account table which joins to the Fact table. I then:
    1.     Created an “Account” dimension
    2.     Created a child “Account Total” level
    3.     Created two (2) children off of the “Account Total” level: (1) Account Address Country and (2) Account Hierarchy Top Level
    a.     Key for “Account Address Country” was the Country column from Account Address (logical)
    b.     Key for “Account Hierarchy Top Level” was the Top Level Account Name from Account Hierarchy (logical)
    4.     Off of “Account Address Country”:
    a.     Created a (1) child off of “Account Address Country” called “Account Address State” with the State field from the Account Address (logical) as the key
    b.     Created a (1) child off of “Account Address State” called “Account Address Detail” with the ROW_WID from the Account Address (logical) as the key
    c.     Created a (1) child off of “Account Address Detail” with the ROW_WID from the Account (logical) as the key
    5.     Off o “Account Hierarchy Top Level”:
    a.     Created a (1) child off of “Account Hierarchy Top Level” called “Account Hierarchy Level 1” with the Top Account ID from Account Hierarchy (logical) as the key
    b.     Created (1) child off of “Account Hierarchy Level 1” called “Account Hierarchy Detail” with the ROW_WID from “Account Hierarchy” as the key
    c.     Crated a (1) child off of “Account Hierarchy Detail” with the ROW_WID from the Account (logical) as the key
    The global consistency check completed with no errors or warning with this design. It appears that perhaps you need to have all of the logical table keys in the dimension path that trace to the Fact table. One other note, cannot repeat use of other columns in the dimension except for the key of the first logical table.
    Please let me know if I missed something.

  • 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

  • Facts and dimensions joins

    Hi,
    Can we use three fact tables in rpd and not join them? We have three facts and four dimensions. All the four are common dimensions to the three fact tables. So in the physical joins can we just join the facts to the dimensions? will it be accepatble if we do not have a join between fact tables. Is it necessary that all the tables (fact and dimensions) need to be joined to some tabler? Can we leave the joins between the facts which are not necessary? Please advice.

    We do not do joins between fact tables, the joins between facts will be happened through dimensions (conformed dimensions).
    In your case the 4 dimension will act as an conformed one.
    Is it necessary that all the tables (fact and dimensions) need to be joined to some tabler? You cannot have a table in BMM which is not joined to any other table.
    Can we leave the joins between the facts which are not necessary?Yes, Dim1 - fact1 -Dim 2 in this fact 1 is connected with Dim1, Dim2 and there is no relationship for fact1 with Dim3 so we don't join it.
    Dim1,Dim2,Dim3 is joined with fact2 in this case Dim 1 and Dim2 will act as conformed dimesion between fact1 and fact2, where as dim3 will be a non conformed dimesion.
    Thanks,
    Vino

  • 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.

  • Create repository from database model- snowflake facts and dimension joins

    I am working on a project that has a database model similar to the image in the link below.
    There are other few tables around it, but this generally represent the spine or major database model. This is not exactly a snowflake schema as there are no intrinsic hierarchy in the dimension tables. As you can see dim2 and dim4 has one to many relationship with dim3. there are joins between the fact tables as well.
    From some blogs and forum threads, I found out that I can create one fact/dimension table by joining many fact/dimension tables. Is this a right approach? Any thoughts on this model please?
    Thanks,
    Rakesh
    ps: I am using Windows XP Pro and OBIEE 10.1.4.3.1 and right now analyzing the data to create a repository.

    Hi Rakesh,
    As above post says you combine all fact tables into single fact table with other dimension tables so it would become a simple start schema .Go throught these blogs for further information .
    http://forums.oracle.com/forums/thread.jspa?threadID=2124061&tstart=0
    http://www.obinotes.com/2010/08/joins-within-logical-table-sources-in.html#comment-form
    Hope it helps you.Seems your new to forum you sud follow these rules http://forums.oracle.com/forums/ann.jspa?annID=939
    By,
    KK

  • None of the fact tables are compatible error

    Hi All,
    I do see this error (none of the compatible fact table) after setting the content level aggregation on the dimension tables and the fact table. This error i get only when i try to pull the calculated item which is based on a attribute in the fact table. I have an attribute like year in the fact table i need to display like 'CY'||'2013' in a calculated logical column and when i pull this into answers i get this error -
    1) joins are ok ; only one fact table and 3 dimension tables
    2). content level on the fact table are specified at the detail level and also for the dimensions
    any suggestions - thanks for your time

    can anyone please provide some suggestions -
    > i looked at the fact table LTS and specified the logical level for each dimension as the detail
    > specified the LTS for each dimension table
    > I have a column in my fact table which is calendar year and i want to have a derived column like rep_cal_year with 'CY'||cal_year - so when i pull this derived column in my answers i get the error - none of the fact tables are compatibile with the query;
    what could be missign?

  • Lowest Level in Dimension

    HI guys
    i have rdbms 9.0.4
    can i define lowest level of dimension that is not the primary key of the dim table ( this field has unique values)
    or the lowest level of dimension should be the primary key of the dimension table.
    thanks alot.
    Brad

    Hi Matt!
    Glad to read you again!
    I agree with you that in this simple example, I should be able to make this a star schema.
    but :
    - on a functional point of view, this date is an attribute of a vehicle, not of an invoice. But let's ignore this.
    - this problem is the same as one we have in another part of the BM, which is much more complex. In this complex BM, I can't use star schemas because it removes some joins we need in order to perform some reports.
    This is why I'm looking for another way to proceed.
    If you have time to spend on the complex BM, here is a simplified description :
    * in the physical layer, I have:
    - a calendar table with multiple aliases to be used with each dates in the following,
    - an invoice header table
    - an invoice detail table
    with
    some header date -> header table -> detail table
    some detail table -> detail table
    * in the logical layer (stars), i have:
    - my calendar dates with their dimensions
    - an invoice dimension table with the two sources (header + detail) + its dimension
    - an invoice header fact table
    - an invoice detail fact table
    header date -> header fact
    invoice dim -> header facts
    invoice dim -> detail facts
    detail date -> detail facts
    I mus be able to query details facts while showing or filtering the header date. In such a configuration, you'll understand it isn't possible as there isn't any relationship between the detail facts and the header date. This is why the header date should be kept as a dimension of the invoice dimension, which is similar to my basic example.
    Unless I went wrong somewhere?
    Thanks!
    Ced.
    Message was edited by:
    ced

  • Few dimension values used in FACT tables.

    Hello all,
    We are trying to know if somebody faced this issue earlier. We have dimension tables containing 5 million records, but the fact table uses hardly 30k of these dimension values. The fact table contains 350 million records, so is there any way to improve the performance of the query in such a scenario, where hardly 20% of dimension values are actually used by the FACT tables.
    Thanks and Regards,
    Upendra

    nilanjan chatterjee wrote:
    Hi,
    >
    > The data for the parent members should be available in the SQL tables.
    > For example, 2011.TOTAL is parent member. You should not have any data for this member in your database. If it is there, it might have come somehow (may be an import). But this is not right. You might want to remove these records. But be sure that you dont delete the records for the base level members.
    >
    > Hope this helps.
    I guess you meant should not, right ?

  • None of the fact tables are compatible

    hi,
    am developing report from two fact table columns and one dimension table in obiee 11.1.1.5.0.
    am getting error
    Error
    View Display Error
    Odbc driver returned an error (SQLExecDirectW).
    Error Details
    Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
    State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 14020] None of the fact tables are compatible with the query request Fact - Retail.Retail. (HY000)
    SQL Issued: SELECT 0 s_0, "TM Vehicle Sales"."- Offtake Facts"."Offtake" s_1, "TM Vehicle Sales"."- Retail Facts"."Retail" s_2, "TM Vehicle Sales"."Distributor"."Country" s_3 FROM "TM Vehicle Sales"
    regards
    vcm

    need to see your design, dim is shared between the facts?
    I think you can assume the physical query based on your columns selection..
    Now pick one column from 1st fact and 2nd column from dim run a report, get physcial query and verify the joins with obiee and your own query.
    then add column from 2nd query see how it works
    Edited by: svee on Jun 29, 2012 6:21 AM

Maybe you are looking for

  • How to install win 8.1 pro x64 on MBA mid 2013 (core i7)

    Please help me how to install win 8.1 pro x64 on MBA mid 2013 (core i7). Thank you very much for your help. Best regards.

  • Problem in refreshing Tabular Form On closing Modal Page

    Hi ,           I am not able to refresh tabular form region on close of the modal page.           can someone help me ? Thanks and Regards, Madonna

  • Bird's Eye View enabled by default

    Hi all, is there a way to have the bird's eye view enabled by default in the impact/lineage? I need to enable it everytime i do a impact/lineage analyse. It takes to much time before it pops up. I know it's something not very important :) But it's an

  • Unable to connect to service on OVI store...

    so i'm trying to download some apps for my N8, i was able to download 1 app and after that it won't connect at all. it says, "unable to connect service..." i have no problem going to other sites... RANDi

  • AE crashes when I open file Ive been working

    I have been working on a project the past couple of days and now when I try to open it I get the following error and AE crashes. This seems to be the only file that causes the issue. I can open new and past projects and use the software just fine. Th