Categories
- All Categories
- Oracle Analytics and AI Learning Hub
- 34 Oracle Analytics and AI Sharing Center
- 22 Oracle Analytics and AI Lounge
- 277 Oracle Analytics and AI News
- 47 Oracle Analytics and AI Videos
- 16.1K Oracle Analytics and AI Forums
- 6.3K Oracle Analytics and AI Idea Labs
- Oracle Analytics and AI User Groups
- 99 Oracle Analytics and AI Trainings
- 16 Oracle Analytics and AI Challenge
- 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 -