Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Problem with distinct leaf members 1

Status
Not open for further replies.

Flybridge

MIS
Jul 7, 2003
130
GB
I have a couple of cubes that are giving me the same problem.

At the leaf level the users want to see meaningful descriptions. Unfortunately, the source data is not well managed and the same descriptions can be used for different things (!????)

Anyway, to get around this, the leaf level is keyed on the code, but the description is a concatenation of the code and the description.

The problem is, I get an error message when processing the cube saying there are non-unique members at that level. If I change the description to be just the code it processes fine. As the codes are unique the concatenations must be unique, so why do I get this error message? And how can I get descriptions at the leaf level?

Thanks in advance,

Flybridge


'The world isn't round - it's bent!' Spike Milligan
 
When you associate the code with the description in the dimensional hierarchy, make sure the code is listed as unique but the description is marked as not unique.

-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright
 
Thanks, but I have already set the parameters that way, and still get the error message.


'The world isn't round - it's bent!' Spike Milligan
 
Oh, I just thought of something else - uniqueness may be defined as within a certain number of bytes, 30 or 31 perhaps. I know that's true in some places in AS, like column names, even though the rest of SQL Server has a higher limit (or no limit). This is a leftover from when MS bought the product several years ago.

-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright
 
Erm, not sure I understand that.

Are you saying that if the data is of a similar size it is considered to be the same thing? If that is the case, wouldn't consecutive numbers be considered to be the same?

Sorry for being thick!


'The world isn't round - it's bent!' Spike Milligan
 
Let's say the limit is 31. Consider:

5656 Concussion, not otherwise defined.

5656.1 Concussion, severe, with memory loss and associated confusion, no head trauma detected.

5656.2 Concussion, severe, with memory loss and associated confustion, one or more head trauma.

You will notice that these second two diagnosis code descriptions are similar across the first 31 bytes. This is probably because this is the way doctors analyze the patient. If your code descriptions (or column names) show this kind of similarity, that might be your problem.

-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright
 
Ah. Got it.

That could be the problem. There are a lot of similarities like that. I think a rethink is needed.

Thanks, have a star.


'The world isn't round - it's bent!' Spike Milligan
 
Hi Flybridge,

Coming in a bit late here, but NULLS may be the issue. If you concatenate and one side contains NULLS you could end up with a NULL answer. This may happen in more than one place giving non unique members. Trying concatenating with a coalesce around each attribute.
There again, I might be totally off the mark !!!

Ta,
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top