Categories
- All Categories
- 75 Oracle Analytics News
- 7 Oracle Analytics Videos
- 14K Oracle Analytics Forums
- 5.2K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 40 Oracle Analytics Trainings
- 60 Oracle Analytics Data Visualizations
- 2 Oracle Analytics Data Visualizations Challenge
- 3 Oracle Analytics Career
- 4 Oracle Analytics Industry
- Find Partners
- For Partners
[nQSError: 14025] No fact table exists at the requested level of detail
Scenario:
Let suppose we have two Dimension table (A and and Fact Table C, we have joined A & B and B &C on Business Model and mapping layer, but on presentation layer we expose only A and C and we want to fetch result from A and C on presentation Layer but it is throwing error- [nQSError: 14025] No fact table exists at the requested level of detail.
How could we resolve this ?
Answers
-
Do you experience the same issue if you expose Table B in your presentation layer?
Are you able to see the generated SQL in the advanced tab? Is it including Table B as you are expecting it to, or is it being missed?
If Table B is being commited, you may be able to skirt around the issue if you can bring any field from Table B into your Table A at presentation Layer? So that your presentation layer consisted of something like
a.PK , a.CODE , a.NAME , a.DESC , b.NAME
0 -
Yes, I am able to see the same issue if i expose Table B on Presentation Layer,
No, Table B is not there in generated SQL, and if i am exposing A,B,C on presentation layer and fetch atleast one field from them then also i am getting same error.
0 -
Your train of thought should stop abruptly and immediately the millisecond you type out " we have joined A & B ".
You joined your dimensions together? Physically? Unless those two "dimensions" are actually a single branch of a snowflake, then your model is already fundamentally wrong from the start on the physical layer.
In the RPD you have a physical and a logical model which do not necessarily look the same. Also you can't just join things physically and assume that upwards things work "as imagined" in an automagical way. You need to draw an entity relationship diagram first and understand which physical table is supposed to join to which other physical table and which logical entity (NOT table) is supposed to have a relationship (NOT "join") to which entity.
0 -