OBIEE Error 15048

Dennis Hancy

I have a logical table called MyTable Dim.  When I do a global consistency check, all works well.

Next, I added a level based hierarchy in the logical level containing three fields from MyTable Dim.

Now, when I do a global consistency check, it gives me an error on the Business Model.  The error number is 15048:

"The logical table, MyTable Dim, must be a descendant of the root logical table in the associated dimension according to the logical many to one join relationship."

I cloned (or attempted to clone) this table and hierarchy from a table I created earlier that works perfectly.  I can't figure out what this error means though.  I suspect I typo'd something or missed a checkbox somewhere.

Any ideas as to where this error might be coming from?

Thanks!

Dennis

Robert Angel

Take a look at this in my Oracle support; -

After Upgrade To 11.1.1.9 RPD Consistency Check Fails With [15048] Logical Table: Field Must Be A Descendant Of The Root Logical Table In The Associated Dimension (Doc ID 2379127.1)

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=357103117660048&parent=EXTERNAL_SEARCH&sourceId=PROBLEM&… https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=357103117660048&parent=EXTERNAL_SEARCH&sourceId=PROBLEM&id=2379127.1&_afrWindowMode=0&_adf.ctrl-state=145vs2kme8_4

[Deleted User]

Dennis Hancy wrote:I cloned (or attempted to clone) this table and hierarchy from a table I created earlier that works perfectly.

That's your error right there. If you copy out the UDML of your "new" object you'll see that it has inherited quite some relationships of its "cloning ancestor" which mess things up.

Drop the hierarchy and create one the proper way from your originating logical dimension.

Robert Angel

'clone' was too vague for me to comment, I was not sure if we were in the physical or in the logical, and if by clone he meant alias or copy.

Stylistically I like to alias ALL tables, as for me this prevents the 'is this an alias or a table question, they are all aliases, and I use the naming to give a sound steer on the usage in the logical layer.

And it is 'clean' entirely without baggage as you are alluding to above.

[Deleted User]

It's one of those objects you should really never ever copy or drag-and-drop around. There's a whole lot coming across.

Robert Angel

Agreed - I was just not certain what the precise meaning of clone was in the context - I agree totally with you, if that is what he meant!

Dennis Hancy

Hi. 

Thanks for your replies.

By "clone", I simply meant that we have another table very similar to the one I am trying to create.  Among other things, the new one contains a hierarchy similar to the one that already exists.  It is not a copy in the "drag and drop" sense; it's more of a copy in the sense that I tried to create the structure using the same approach used on the original.  It's my attempt to understand what the steps are.  I'm still wrestling with some of the theories and concepts behind BI especially they relate to the RPD file.  Once I have a better handle on that,  I am guessing the mystery of this will all be revealed

After a co-worker and I looked at this more, we determined that the culprit was a join in the logical later that was pointing in the wrong direction.  Neither one of us really understand "why" that worked, but for the moment we're happy we got through this latest hurdle.

Thanks again.

Dennis

[Deleted User]

Dennis Hancy wrote:After a co-worker and I looked at this more, we determined that the culprit was a join in the logical later that was pointing in the wrong direction. Neither one of us really understand "why" that worked, but for the moment we're happy we got through this latest hurdle.

I'd still investigate more in detail as "it works because it works but not sure why" isn't a really sound basis for a long-lived implementation.