This Essbase discussion board is provided as a free service and dedicated to all the Essbase professionals out there!
  << Previous Topic | Next Topic >>Return to Index  

Validation Error -- help needed please

September 13 2013 at 4:27 PM
No score for this post
Jackie N, 
from IP address 108.46.35.229

Getting a validation error on deployment that says I can't have two members by the same name (130), even in two different dimensions (both custom: department and product). we have a department 130 and a product 130 (where 130 corresponds to the Oracle GL segment for that dept and that product). so, if I can't have two by the same name, I need something more than just the GL value as the member name. I'm thinking DEPT-130. And perhaps adding an alias for the Oracle GL value? Any guidance here? I thought best to keep member names as the Oracle GL value where possible. But perhaps that's not easiest. This is our first go at Hyperion, so we don't really understand the long-term implications of these initial decisions. Any guidance?

 
Scoring disabled. You must be logged in to score posts.Respond to this message   
AuthorReply
Cameron Lackpour

74.109.20.23

You're missing a few details...

No score for this post
September 13 2013, 5:56 PM 

EPMA?
Planning?
Essbase?

Assumming Yes, no, and yes, you could theoretically use something called duplicate members to allow you to have the same member in more than one dimension. There are restrictions on how duplicat members work and for that I would suggest you look at the Database Administrator's Guide. On the whole, I'd say that while duplicate members have been around for quite a while their downsides (loading, querying, building) outweigh any benefit.

If it's Planning then you are simply out of luck as Planning does not support duplicate member names.

I guess I should have thrown in HFM -- if so, you're really on the wrong board for that as this is primarily an Essbase board.

Fwiw, prefixes (common) and suffixes (not so common) are the method most use to uniquely name members. It's no big deal, just have a standard way of handling this.

Last comment -- you really should hire a competent consultant who would guide you through all of this. The very fist question (okay, I am complimenting myself by declaring me as competent -- some would argue that point) I would have is: EPMA -- do you need it? Want it? You seem to have jumped into that without any discussion. Many would argue that for Essbase it isn't always a good fit.

Regards,

Cameron Lackpour

 
Scoring disabled. You must be logged in to score posts.Respond to this message   

Javier

96.48.4.220

Re: You're missing a few details...

No score for this post
September 13 2013, 7:08 PM 

"...you could theoretically use something called duplicate members..."

Feeling mean-spirited on Friday the 13th?

 
Scoring disabled. You must be logged in to score posts.Respond to this message   
Cameron Lackpour

74.109.20.23

Essbase + EPMA seems to be enough pain

No score for this post
September 14 2013, 9:40 AM 

I don't know if I would inflict duplicate member names on anyone, especially with the above combination.

I have, btw, played around quite a bit with EPMA, Essbase, and its (EPMA's) many, many, many tables. Sooner or later I am going to have a massive blog post on all of my findings. Hmm, sounds like sooner or later I'm going to have a massive heart attack. Well, I may have one of those, but hopefully not on this particular subject. Hacking EPMA has been a most interesting journey. I can quite confidently state that they have fully normalized the EPMA dimension libraries.

Regards,


Cameron Lackpour

 
Scoring disabled. You must be logged in to score posts.Respond to this message   
Jackie N,

108.46.35.229

Re: You're missing a few details...

No score for this post
September 17 2013, 10:59 AM 

Thanks for your help Cameron.

What would be the downside of using duplicate members? Would you recommend using that?

I guess my question is regarding best practices for naming in this case.

Thanks,
Jackie

 
Scoring disabled. You must be logged in to score posts.Respond to this message   
Cameron Lackpour

74.109.20.23

Might be a case of tribal knowledge more than anything else

No score for this post
September 17 2013, 12:13 PM 

Duplicate member names are a new (well, how about seven year old, so mature really) feature that isn't used all that much. It isn't supported in Planning, so that cuts out a huge swath of new BSO (and now ASO) Essbase databases.

Beyond that, I think the reasons it hasn't been popular are:
1) You must supply the unique key (whatever parent/child relationship defines the member as unique). This is a PITA to do because often SQL data sources are not stored this way.
2) What goes in must be handled the same way in reporting -- this is viewed by many as cumbersome.
3) Calculations also require the same explicit key when directly addressing the member(s).
4) We just don't use them.

Look in the DBAG and then go to the index and scroll to "duplicate". There are a bunch of caveats and requirements that go around using them.

Having said all of that, I don't know if duplicate members are such a bad idea. But is it really necessary? Couldn't you just do as you wrote, stick a "DEPT-" and a "PROD-" in front of the appropriate 130 member name to differentiate the two? That would be really, really, really simple and you get around all of the duplicate member name issues. So long as you are consistent (gah, you could even do it in a load rule field edit although I will be very annoyed with you if you don't do it in the data source via SQL as no one can read !@#$ing Load Rules a month after they have been created).

I can't think of many downsides to the above approach.

Regards,

Cameron Lackpour

P.S. If you have consultants on your implementation, I would buy them a collective cup of coffee and discuss this. Ask for *their* pros and cons. If you don't have a couple of *competent* consultants on the project, you really owe it to yourself to do so. I am happy to type away (hey, the advice is worth exactly what you paid for it -- nothing) on a forum but this isn't the best medium to impart Essbase good practices.


 
Scoring disabled. You must be logged in to score posts.Respond to this message   
 
  << Previous Topic | Next Topic >>Return to Index  

RSS feed for this forum - http://www.network54.com/Forum/58296?xml=rss. Please email hypess (at) gmail.com, if you have any questions/feedback/issues.