I don't understand from your example how this is a test of "remove unspecified". I don't associate "remove unspecified" with sort order.
I've definitely seen the behavior where new members are always 'tacked on' at the bottom of the list though.
Hi Tim, thx for getting in... indeed I am not speaking about sort order but just input file order.
What I mean is that for an existing ASO dimension new members will be created at the end (after last sibling) and not placed or ordered as specified in the file.
So not only members are not correctly ordered but created "at the end" and also remove unspecified option does not seems to help here... I did not tested with 188.8.131.52 yet.
OK, yes - this is the behavior I've always seen. I don't think I've ever expected "remove unspecified" to help with this - am I misunderstanding you?
The only way this will work is to have a dummy file with a single member in it and use remove unspecified in the rule. then process that file and your real file (in a single MaxL statement) it will drop all members except the one then add the members back in from your real rule. It will put them in order
Indeed you are right Tim, however this is not the case in BSO (and without mentioning "remove unspecified")...
Really? I did not know that was a BSO/ASO difference.
I think I've always used the approach Glenn mentions, or had a 'template' outline with none of the child hierarchies as my starting point.
Thank you guys, Tim and Glenn.
I created and batched the template in order to initialize the build process the concerned ASO cube.
Isn't this the beauty of Essbase... learning new stuff everyday even after 15 years of practice..?!
Tim just try it once because this something I spotted while working on an ASO project, could be related to the version being used 184.108.40.206.500. I will check on 220.127.116.11 and advise further on.
Have a god day.