tag:blogger.com,1999:blog-7650953985627040991.post6522977372430258106..comments2024-02-14T05:30:55.538-05:00Comments on Cameron's Blog For Essbase Hackers: Stupid Programming Tricks No. 30 -- FIXing Stupid Programming Tricks No. 15 with @SHARE and @REMOVECameron Lackpourhttp://www.blogger.com/profile/07701786303677521318noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-7650953985627040991.post-72524894892194096212016-11-10T21:15:44.784-05:002016-11-10T21:15:44.784-05:00Hi Cameron, i have a calc that i cannot figure out...Hi Cameron, i have a calc that i cannot figure out how to get it to work. I need all levmbrs of (org unit,2) to equal the value on the first child with data<br /><br />Orglvl3<br /> Orglvl2 #missing<br /> Orglvl1 =10<br /> Org00<br /> Org01<br /> Orglvl10 =10<br /> Org02<br /><br />I need orglvl2 to =10 not 20 and i cant specify specifc members do to size of all the dimension involved. <br />Any ideas? I tried to agg using fixed and excludes but level 2 still just aggs all childrenAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7650953985627040991.post-86493330482606632212016-10-31T15:34:16.357-04:002016-10-31T15:34:16.357-04:00@RELATIVE will give you more flexibility in the lo...@RELATIVE will give you more flexibility in the long run. Also, by always using @RELATIVE it is one fewer command to explain to the client. I use @RELATIVE whenever I can so that I can isolate to a small portion of a database for testing/debugging. In Planning applications, this is something that one will take advantage of for business rules that have run time prompts. You can't isolate to a subset of Lev0 members using the @LEVMBRS command. $0.02Billhttps://www.blogger.com/profile/17570690057828826521noreply@blogger.comtag:blogger.com,1999:blog-7650953985627040991.post-66689782260877408882016-10-31T14:09:41.390-04:002016-10-31T14:09:41.390-04:00i think so to
but if you have some free time c...i think so to <br /> but if you have some free time can u test @LevMbrs - because some papers sad what this function more prefer then @Relative <br /><br /> i am always use @merge and if , and only your this post open my mind why @remove don't work as i expected ))) er77https://www.blogger.com/profile/02314036829317745809noreply@blogger.comtag:blogger.com,1999:blog-7650953985627040991.post-12891157024302808842016-10-31T05:51:19.820-04:002016-10-31T05:51:19.820-04:00ER,
No, sorry, I did not try @LEVMBRS. Is there ...ER,<br /><br />No, sorry, I did not try @LEVMBRS. Is there some reason you'd expect it to differ? From my experience, @LEVMBRS and @RELATIVE behave identically.<br /><br />Regards,<br /><br />Cameron LackpourCameron Lackpourhttps://www.blogger.com/profile/07701786303677521318noreply@blogger.comtag:blogger.com,1999:blog-7650953985627040991.post-46854581628819654322016-10-31T05:50:23.538-04:002016-10-31T05:50:23.538-04:00Glenn,
Isn't Actual (strangely but not really...Glenn,<br /><br />Isn't Actual (strangely but not really to get the account dimension calcing right as I recall) dense? I'd then have block creation issues. The use of a sparse member such as Connecticut causes the blocks to be created.<br /><br />Sorry, I should note that while I have SET CREATEBLOCKONEQ ON in the code, that's no long necessary as several have documented. Old habits die hard.<br /><br />Regards,<br /><br />Cameron LackpourCameron Lackpourhttps://www.blogger.com/profile/07701786303677521318noreply@blogger.comtag:blogger.com,1999:blog-7650953985627040991.post-30632315368366574522016-10-31T02:04:05.283-04:002016-10-31T02:04:05.283-04:00did you see(test) @levmbrs function ?
https://do...did you see(test) @levmbrs function ?<br /><br />https://docs.oracle.com/cd/E12032_01/doc/epm.921/html_techref/funcs/levmbrs.htmer77https://www.blogger.com/profile/02314036829317745809noreply@blogger.comtag:blogger.com,1999:blog-7650953985627040991.post-28044756054660100302016-10-28T18:26:44.680-04:002016-10-28T18:26:44.680-04:00we all go through this pain. Thanks for the post. ...we all go through this pain. Thanks for the post. would it not have been better to use "Actual" instead of Connecticut for your block statement, I'm sure there are less members in scenario than in market and you would be doing a dense calculationGlennShttps://www.blogger.com/profile/12820725959526528201noreply@blogger.comtag:blogger.com,1999:blog-7650953985627040991.post-52329245954307312212016-10-27T10:34:26.895-04:002016-10-27T10:34:26.895-04:00I'll play. 2012-OCT - I was working on a proje...I'll play. 2012-OCT - I was working on a project in Canada. It took me all of a few seconds -- I was up there for 5 years with only a short break for a project in the US in 2010, so it was a pretty easy one to remember.<br /><br />And to comment on the actual purpose of your post... <br /><br />I hate it when I realize I am tackling the same problem years later. I like to think I would remember that stuff. I've started creating little files in Google Docs where I save examples of code that have annoyed me. <br /><br />While I tell people the ol' FIX/IF rule, I don't always follow it. There's an "it depends" that I don't share with noobies. I like to think about it from the standpoint of how many of the members in the FIX do I expect to actually need to touch. If I plan on touching/changing 100% (or almost 100%) of the blocks identified in the FIX then I don't usually care if it is a dense or sparse dimension. This has become more and more my MO now that we can use THREADVAR/FIXPARALLEL to simplify complex (nested) IF statements.Billhttps://www.blogger.com/profile/17570690057828826521noreply@blogger.com