I'm designing a RPD
model based on a relational database model, and have run into a really weird
issue, that I never even though was possible.
The model does work for several combinations, but in few instances, I get following error when I run an analysis report:
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: 17001] Oracle Error code: 904, message: ORA-00904:
"T380"."REQUISITION_LINE_ID": invalid identifier at OCI call
OCIStmtExecute. [nQSError: 17010] SQL statement preparation failed. (HY000)
…………………….
So far so good, but I
uncover a strange phenomenon, when I pull up the SQL query generated by the BI
Server:
WITH
SAWITH0 AS (select distinct T8727.SEGMENT1 as c1,
T8727.SEGMENT2 as c2
from
PO_DISTRIBUTIONS_ALL T1819 /* Fact_PO_DISTRIBUTIONS_ALL */ ,
PO_REQUISITION_LINES_ALL T533 /* Fact_PO_REQUISITION_LINES_ALL */ ,
MTL_CATEGORIES_B T8727 /* Dim_MTL_CATEGORIES_B_Purch_Category */
where ( T380.REQUISITION_LINE_ID = T533.REQUISITION_LINE_ID and T533.CATEGORY_ID = T8727.CATEGORY_ID ) )
select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3 from ( select distinct 0 as c1,
D1.c1 as c2,
D1.c2 as c3
from
SAWITH0 D1
order by c2, c3 ) D1 where rownum <= 65001
SAWITH0 AS (select distinct T8727.SEGMENT1 as c1,
T8727.SEGMENT2 as c2
from
PO_DISTRIBUTIONS_ALL T1819 /* Fact_PO_DISTRIBUTIONS_ALL */ ,
PO_REQUISITION_LINES_ALL T533 /* Fact_PO_REQUISITION_LINES_ALL */ ,
MTL_CATEGORIES_B T8727 /* Dim_MTL_CATEGORIES_B_Purch_Category */
where ( T380.REQUISITION_LINE_ID = T533.REQUISITION_LINE_ID and T533.CATEGORY_ID = T8727.CATEGORY_ID ) )
select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3 from ( select distinct 0 as c1,
D1.c1 as c2,
D1.c2 as c3
from
SAWITH0 D1
order by c2, c3 ) D1 where rownum <= 65001
Notice carefully the
where clause, it refers to alias table T380, but that alias table does not
exist in the FROM clause. Weired?? Totally!! I was expecting a "Unable to Navigate" error if BI could not determine the join path and in no case an incorrect query, and yet here we have it.
I start digging into
a work around, and a reason behind this. I did following while modelling my
physical and business layers:
- Created physical joins the way relational tables are joined, just making sure that there was only one path to reach every table, and not multiple. (BTW, news flash on a side note: OBIEE does support circular joins in physical layers, not in logical BMM layer though).
- I created a logical star schema in the BMM layer, by pulling all the facts columns into one logical fact table, and pulling the attributes to respective dimensions. This also meant most logical table sources had more than one physical table sources.
- For attributes that were coming from fact source tables, I created another logical dimension, and pulled those attributes to this logical table, and joined it to logical fact in the BMM layer.
- The logical dimension that was getting attributes from fact sources, had more number of sources than the logical facts, as I did not want to create logical dimension for every single attribute.
The
last point #4 was causing several query errors, so I gave up being lazy, and
next I created a dimension for every attribute not coming from the fact
sources. This was to ensure logical sources in Fact table were the same as
logical sources in fact details dimension.
I
did end up with lot less errors, but occasionally I still get issues on the front
end. I'm still trying to find a solution for all the scenarios, hopefully I can
write next article as soon as I have a solution to this. Stay tuned.
My
first observation is the issue happens if your source is a heavily relational
data model, where one logical table has multiple sources. The source is also
heavily snow-flaked.
Second
it could be linked to OBIEE version 11.1.1.7.0 or close to that. As I have
never experienced this kind of issue in the past. Lets see. Hopefully soon I
will have an answer.
It might occur with drag and drop on physical columns.
ReplyDeleteCheck the physical join between your fact and dimension tables: the link should be there, but the join condition should be wrong (OTHER_TABLE.FK = DIMENSION.PK instead of FACT_TABLE.FK = DIMENSION.PK).