This is what i have used couple of time to quickly get around this
- Get an extract of current cube
- Move the members that you want to rename under a 'dummy' parent using a parent child rule file
- remove the dummy parent bucket, you will lose the data but that is fine
- Load new members names under their required parent using a parent child rule file
- Load old member names as Alias to new member name using Alias table (ALT) file. You can use a new alias table for this purpose.
- Load the original extract to cube
- Remove the new alias table
You will get your members renamed
Good idea, Sunil, and I've done this in the past. You don't even necessarily need to do that 'dummy parent' stuff if you have a source file from which you can build the entire dimension again with the 'remove unspecified' option.
I've also used Glenn's approach.
What you really must think about in either situation is whether any of the new names match existing member names. That definitely complicates things.
Honestly, if you don't already have the code written, for a strictly one-off 100 member change it would probably be faster to suck it up and work through them in EAS. But where's the fun in that, right?
Thanks Tim - Yes building an entire dimension is also an option if it is possible
I just wonder why does Oracle not provide this as an Out of Box feature of ESSBASE (not sure if it is in their plan for future releases). Member name changes are pretty normal occurrences during implementation and even afterwards, during operations, as business changes over time
Yes, I think we've all become so used to it not being possible that we don't really stop to think "this is an unnecessary limitation".
I know keeping the data in the right place gets complicated if "A" changes to "B" and "B" changes to something else, but you have to consider those problems when doing it manually anyway, so it's not like a load rule option would be at any special disadvantage.
As typical, I want to take a contrarty view, member names should not change in Essbase much. If planned right, the member names are typically codes at are fairly static but the aliases change based on business needs. Yes I know there are instances where this is not possible but in most implementations it should be the exception rather than the rule. IT is easy to change aliases, as you see, much harder to change members
True - as you said, it just depends on the implementation and what we do with it over time - Sometimes insufficient metadata governance leads to names changes or other times it could be other technical reasons e.g. trying to interface with another new system that needs some codes differently