ASO MDX member formula and performance

Hi,
I am doing some testing about MDX formulas and performance. I found a performance issue but I can not understand why is taking so long time a report.
The situation is:
I create a report or a MDX query with:
6 dimensions in row and 1 dimension in column
rows:
Period - Filtered using a member
Year - Filtered using a member
Relationship Manager - Filtered using a member
Report Type - Filtered using a member
Local Relationship Manager - 4400 members level 0
Global Relationship Manager - 10400 members level 0
Column:
Account dimension, only a member
The member selected for Report Type (RM.Local) has a formula
My Report Type dimension has 10 members, there is one member where I store data called : RM.Input
My first test was
RM.Local his formula is [RM.Input] , the report is run in 1 second
RM.Local his formula is ([RM.Input],[MTD]) where MTD is a member level 0 store in my view dimension. The report run in 20 minutes. I was not expecting so bad performance when I only pointing at [RM.Input],[MTD]
Do you consider this time is reasonable when I am using this formula?
The mdx report is:
With
set [_Local Relationship Manager3] as 'Descendants([All Local Relationship Managers], 2)' = level 0 members
set [_Global Relationship Manager4] as '[Global Relationship Manager].Generations(4).members' = level 0 members
set [_Period0] as '{[Period].[Oct]}'
set [_Relationship Manager4] as '{[Relationship Manager].[Dummy1)]}'
set [_Report Type0] as '{[Report Type].[RM.Local]}'
set [_Year2] as '{[Year].[FY-2013]}'
select
{ [Account].[Expenses]
} on columns,
NON EMPTY {crossjoin({[_Local Relationship Manager3]},crossjoin({[_Global Relationship Manager4]},crossjoin({[_Period0]},crossjoin({[_Relationship Manager4]},crossjoin({[_Report Type0]},{[_Year2]})))))} properties MEMBER_NAME, GEN_NUMBER, [Global Relationship Manager].[MEMBER_UNIQUE_NAME], [Global Relationship Manager].[Memnor], [Local Relationship Manager].[MEMBER_UNIQUE_NAME], [Local Relationship Manager].[Memnor], [Relationship Manager].[MEMBER_UNIQUE_NAME], [Relationship Manager].[Memnor], [Period].[Default], [Report Type].[Default], [Year].[MEMBER_UNIQUE_NAME], [Year].[Memnor] on rows
from [DICISRM.DICISRM]

Ok Try this one
But here you have to change the MDX formula every month.
Year
--FY2009
--FY2010
--FY2011
--FY2012
Period
--TotalYear
----Qtr1
-------Jan
-------Feb
-------Mar
Let say if you're CurrentYear  is FY2011 and you're Current Month is March then you're MDX will be
case when contains([Year].CurrentMember,MemberRange([FY2009],[FY2010])) and contains([Period].CurrentMember,MemberRange([Jan],[Feb]))
Then
B
else
C
end
For the Next month you just have to make a change in the MemberRange I.e.,(Replace Feb with Mar)
*case when contains([Year].CurrentMember,MemberRange([FY2009],[FY2010])) and contains([Period].CurrentMember,MemberRange([Jan],[Mar]))*
Then
B
else
C
end
I tested it and Its working fine.
I think this will solve you're problem but there might be a more elegant solution out there.
Regards,
RSG

Similar Messages

  • Problem with member formulas and allocation

    Hi guys,
    I am experiencing a problem I am not currently able to solve. I'm building a planning application in which
    volumes can be inputed in different units of measure (5 are currently available). For example a user can input in liter or KG, and the
    system converts this data in all the different units of measure available, executing a script logic after
    the input (for every bas member is also stored a conversion factor, which is used  by the logic for conversion).
    Two are the major issues of this approach:
    1) storing 5 different volumes for every SKU is consuming in term of disk and DB space;
    2) script logic must be executed every time the user sends data and in some cases this could be time-consuming.
    The solution I'm trying is to use member formulas in order to calculate different units of measure, storing
    only one of these. However, this way lead to another problem: when I try to input data with a top-down approach, using BPC
    ALLOCATION ENGINE, I cannot use the correct unit of measure as a driver for the spread.
    For example, if I input volumes is KG, and the unit of measure stored is only liter, I cannot use nor KG as a driver (because is not stored,
    but only a member formula) neither liter, because the spread using this driver would lead to a wrong result.
    What I would like to do is to give the user the possibility to input in the desired unit of measure at an aggregated level and spread data
    using the existing mix, which must be volumes with the same unit of measure used for input.
    Does anyone has an idea that could help me?
    Regards
    Edited by: utenza pubblica Public on Oct 23, 2009 4:48 AM

    hi
    i found a solution for the Problem in another Forum
    http://businessintelligence.ittoolbox.com/groups/technical-functional/hyperion-admin-l/dynamic-calc-formulas-not-refreshed-1719379?cv=expanded
    The suggestion is
    1. change the Member from Dynamic Calc to Store
    2. Refresh (After these Step the Formulas where still out of sync)
    3. change the Member from Store to Dynamic Calc
    4. Refresh
    After these Steps the Formulas are in sync again.
    Kevin Kraft
    Edited by: Kevin Kraft on Mar 25, 2009 12:33 PM

  • ASO MDX queries

    Hi,
    Is there any possibility that we can use semicolon at the end of MDX member formulas for ASO database? If yes please let me know how we can write and calculate member formulas with semicolon at the end?
    One thingI know for sure is we should not use semicolon at the end of member formulas for ASO in admin console.

    Syntax has changed for ASO member formulas and semicolons are no longer used. Why would you want to use the semicolon? With the new syntax it is not necessary.

  • Which is faster - Member formula or Calculation scripts?

    Hi,
    I have a very basic question, though I am not sure if there is a definite right or wrong answer.
    To keep the calculation scripts to a minimum, I have put all the calculations in member formula.
    Which is faster - Member formula or calculation scripts? Because, if i am not mistaken, FIX cannot be used in member formulas, so I need to resort to the use of IF, which is not index driven!
    Though in the calculation script,while aggregating members which have member formula, I have tried to FIX as many members as I can.
    What is the best way to optimize member formulas?
    I am using Hyperion Planning and Essbase 11.1.2.1.
    Thanks.

    The idea that you can't reference a member formula in a FIX is false. Here's an example:
    - Assume you have an account that has a data storage of Stored or Never Share.
    - This account is called Account_A and it has a member formula of Account_B * Account_C;.
    - You would calculate this account within a FIX (inside of a business rule) something like this:
    FIX(whatever . . . )
    "Account_A";
    ENDFIX
    If you simply place the member named followed by a semi-colon within a business rule, the business rule will execute the code in the in that member's member formula.
    Why would you want to do this instead of just putting ALL of the logic inside the business rule? Perhaps that logic gets referenced in a LOT of different business rules, and you want to centralize the code in the outline? This way, if the logic changes, you only need to update it in one location. The downside to this is that it can make debugging a bit harder. When something doesn't work, you can find yourself searching for the code a bit.
    Most of my applications end up with a mix of member formulas and business rules. I find that performance isn't the main driving force behind where I put my code. (The performance difference is usually not that significant when you're talking about stored members.) What typically drives my decision is the organization of code and future maintenance. It's more art than science.
    Hope this helps,
    - Jake

  • Execution order: Business Rule vs. Dynamic Member Formula

    Hi,
    I have a problem with a calc rule that calculate percentage of a list of account in comparison with other account (Ce10) as below
    FIX (list of account restricted here, @IDescendants(YearTotal),....)
    "Percentage"
    (IF (@ISUDA(Account,"Ce10"))
    "Percentage" = "NA CE"/"NA CE"->"CE10"; //Here the percentage member and "NA CE" member in the same dimension
    ENDIF)
    ENDFIX
    When I run the rule, the result is ok with the Months. But in the Quater and YearTotal, it's automatically aggregate to a wrong result as the YearTotal is dynamic calc (e.g: Jan: 10%; Feb: 10%; Mar: 10% => Q1: 30%). So I thought it because the Rule is executed first (Q1=10%) but after that, the dynamic aggregation of Year is executed so Q1 is aggregated as 30%.
    So how to fix Q1 = 10% as expected result. I did study on two pass calculation but it seem can not apply on this isssue. I searched for "back calculation" also but I still didn't find any solution for this.
    Please help me on this.
    Thanks.

    Thanks JM for quick responding. The problem here is "Percentage" is not a account's member.
    To make the question more clearly, I'll explain the rule:
    There's a list of account A: A1, A2,...,An
    and a list of account B: Ce10, Ce20, ..., Ce90
    There is a mapping n-1 between these two lists. For example, A1, A2 is mapped to Ce10, A3 to A5 is mapped to Ce20 and so on. I do it by assigning UDA (e.g: A1 {Ce10}, A2 {Ce10}...)
    And the rule is used to calculate percentage of accounts of list A in comparison with equivalent account in list B. So the percentage can not be account member. It's the reason why I can not use member formula and two pass calc here.
    Regards,
    Huy Van
    Edited by: Huyvtq on Jan 9, 2013 9:50 PM

  • Not triggering  Member Formula

    Hi,
    I have created a simple member formula and have processed it. It shows up as Green. But it is not getting triggered when I refresh or save data through EPM Excel Workbook. I have verified that the data exists for the 2 accounts shown below. Please help!!!
    Regards,
    Nicky

    Hi Nicky
    You haven't specified which version of BPC you are currently on, but this might be of help.
    The following SAP Note might be relevant to you if you are on BPC on HANA.
    2122679 - Member formula result member returns no data
    If this note is not applicable to you, then possibly try using the fully qualified path for dimension member in your formula.
    For Example: [ACCOUNT].[PARENTH1].[400000] + [ACCOUNT].[PARENTH1].[600010]
    Hope this helps,
    Kind Regards
    Daniel

  • Essbase 11.1.2.1 - Converting BSO Member Formula to ASO MDX Formula

    Hi all,
    I'm quite new at Essbase and I'm currently using Essbase 11.1.2.1. I have 2 cubes: one is a BSO cube and the other is an ASO cube.
    In the BSO cube, I have an account that has member formula:
    IF(@ISATTRIBUTE("US"))
    ("Sales"->"Budget"->"USD")-("Sales"->"Actual"->"USD");
    ELSEIF(@ISATTRIBUTE("EU"))
    ("Sales"->"Budget"->"EUR")-("Sales"->"Actual"->"EUR");
    ELSEIF(@ISATTRIBUTE("UK"))
    ("Sales"->"Budget"->"GBP")-("Sales"->"Actual"->"GBP");
    ENDIF
    Notes:
    - Sales is an account
    - US, EU, and UK are members of Country attribute dimension
    - Budget and Actual are members of Scenario dimension
    - USD, EUR, and GBP are members of Currency dimension
    I understand that the member formula for BSO and ASO are different. Can anyone please advise me on what the formula should be in ASO cube as MDX formula?
    Thank you very much!

    CASE [Currency].CurrentMember.[Country]
         WHEN "US" THEN ([Sales], [Budget], [USD]) - ([Sales], [Actual], [USD])
         WHEN "EU" THEN ([Sales], [Budget], [EUR]) - ([Sales], [Actual], [EUR])
         WHEN "UK" THEN ([Sales], [Budget], [GBP]) - ([Sales], [Actual], [GBP])
         ELSE 0
    END
    *Note that I am assuming Country is an attribute of Currency based on the information provided.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • BSO member formula conversion to ASO MDX

    Hi guys !
    I am trying to convert the following BSO member formula to ASO.
    My BSO member formula is :
    "FPP70" -> "FPP" / "B70" -> "AP";
    In ASO member formula I tried : (FPP70, FPP / B70, AP) but I have a syntax error with '/'
    Can anyone please help me out with this?
    Thanks,
    Jonathan

    oops sorry, I made a minor mistake. you don't need the {}
    It should be
    ([FPP70],[FPP]) /([ B70], [AP])
    If this is a subset of another calculation you would wrap the whole thing in parens
    (([FPP70],[FPP]) /([ B70], [AP]))
    ([FPP70],[FPP] ) is a tuple

  • Essbase ASO - How to aggregate all Parents in multiple dimensions when using member formulas

    We are trying to add a few MDX member formulae on some of our Accounts in the ASO cube. We recently understood that member formulas in ASO calculate both LEVEL0 and Parent members of other dimensions, So we are trying to tell Essbase to calculate LEVEL0's only and to aggregate all other levels in all dimensions. However we are unable to get the syntax right. Below is what we so far have
    AccA has below formula:
    CASE WHEN ISLEVEL([Period].Currentmember,0)
    THEN
    AccX+AccY
    WHEN ISLEVEL([Period].Currentmember,1) OR ...etc
    THEN SUM({LEAVES([Period].Currentmember)},[AccA])
    END
    This does work fine and gives correct values for Parent members in Period dimension. But we also have 3 other dimensions like Product, Area and Entity. We tried the below but this throws an error during retrival.
    CASE WHEN ISLEVEL([Period].Currentmember,0)
    THEN AccX+AccY
    WHEN ISLEVEL([Period].Currentmember,1) OR ...etc
    THEN SUM({LEAVES([Period].Currentmember),LEAVES([Product].Currentmember)},[AccA])
    END
    Should we add multiple SUM commands in there? All we want to do is tell Essbase to aggregate all other dimensions to parent levels. Please help.

    Sorry to reiterate the post again.
    DanPressman Was wondering what would be other way to write calculations other than Accounts.
    I have a case where the user wants to calculate Ending Equity and this should be calculated at level0 using the rates and all parents of entity has to aggregate.
    1. Level0 of entities calculate with rates
    2. aggregate its children to parent entity
    I have used solve order to get it work but taking a lot of time.
    Is there any other alternative way of doing it? Which other dimension i can choose to perform this calculation? This is exactly similar to productsum calculation

  • Problem working on member formulas in ASO cube

    Hi
    I was asked to convert a planning application BSO cubes into a single ASO cube.I have managed to convert one BSO Cube into ASO through EAS console and added the members in the other BSO cube throgh rulesfile.
    Now i have to write the member formulas for the level0 members of Account dimension.These are very simple formulas like
    if(@ISMBR("New_Seats"))
    "Assets Value"="Total Asset Cost";
    else
    "Assets Value"="Asset_Value";
    endif;
    and
    "Empty_Seats"=(("New Seat Additions"+"Available_Seats")-"Required_Seats");
    This is the first time i am working on ASO.I am getting this error while writing these formulas
    "Error(1260052) syntax error in input mdx query on line 1 at token '=' Empty_Seats..."
    Help me in writing these formulas and also in selecting proper member properties.

    The hierarchy is like
    Account(gen1)
    -> Statistical_Account(gen2)
    ->New Seat Additions(gen3)
    I have tried tthis and the formula is verified successfully
    *([Statistical_Account].[New Seat Additions]+[Statistical_Account].[Available_Seats])-([Statistical_Account].[Required_Seats])*
    if i use *([New Seat Additions]+[Available_Seats])-[Required_Seats]* it is not veryfying throwing some syntax error
    Thanks

  • Converting Member Formulas to MDX

    Hi Experts!
    I'm converting member formulas to MDX for an ASO cube I created and I'm having trouble with the ones that use @MDSHIFT. I'm new to MDX and trying to learn as I go. One of the formulas I'm struggling with is:
    IF( @ISMBR("Budget"))
    (("Operating Results"-
    (@MDSHIFT("Operating Results", -1, "Years", , 10,"Budget",)+
    "Reclassification Operating Results"))/
    (@MDSHIFT("Operating Results", -1, "Years", , 10,"Budget",)+
    "Reclassification Operating Results"))*100;
    ELSEIF( @ISMBR("Business Plan"))
    (("Operating Results"-
    (@MDSHIFT("Operating Results", -1, "Years", , -4,"Business Plan",)+
    "Reclassification Operating Results"))/
    (@MDSHIFT("Operating Results", -1, "Years", , -4,"Business Plan",)+
    "Reclassification Operating Results"))*100;
    ELSE
    (("Operating Results"-
    (@MDSHIFT("Operating Results", -1, "Years",)+
    "Reclassification Operating Results"))/
    (@MDSHIFT("Operating Results", -1, "Years",)+
    "Reclassification Operating Results"))*100;
    ENDIF;
    This is for a change year over year % member. Any help would be much appreciated! Thanks!
    -Cheers

    In all honesty - it looks like you should not just 'convert it.' I dont see any real need to use MDSHIFT here. I would just use PrevMember function for years, while hardcoding the scenario into the tuple.

  • Why does commenting out calculated member formulas in BIDs cause several minutes of CPU spike and non-responsive BIDs?

    I'm using SQL Server 2012.  I have noticed that commenting out calculated member formulas in BIDs (like even just 10 lines of formula) can cause BIDs to throttle all the CPU and become unresponsive for minutes.  What could be the cause of that?

    Hi Lee,
    According to your description, you get high CPU usage when commenting out the calculated member formulas. Right?
    With your information, we are not sure this is a MDX Query performance issue or the BIDS issue.  We suggest you optimize your MDX query and diagnose the Formula Engine performance. Please refer to the links below:
    Query Performance Tuning in Microsoft Analysis Services: Part 2
    Analysis Services Query Performance Top 10 Best Practices
    If possible, please post some screenshots or detail information about calculated member formulas so that we can have some deep analysis.
    Best Regards,
    Simon Hou
    Simon Hou
    TechNet Community Support

  • MDX and performance

    I know dimension formulas impact performance drammatically but I don't really understan how i works.
    I have formulas in two different hierarchies, but it seems as if the formulas in both hierarchies is calculated every time I run a report whether the report will only show data from one hierarchy.  Must the system calculate all formulas everytime?

    Our current hardware setup is like this
    ·         Single server
    ·         Processors: 2 x Intel(R) Xeon(R) CPU E5320  1.86GHz
    ·         Harddrives: One physical drive SAS 15000 rpm
    o    C: 32 gb SAS Os
    o    D: 35 gb SAS Program
    o   E: 272 gb SAS Data.
    ·         4 GB Ram
    ·         System: Microsoft Windows Server Standard Edition 2003, SP2
    ·         SQL Server 2000
    And this is our dimension formulas:
    //This is where Stampen-specific MDX calculations begins
    //Hierarchy 1
    *Function Hir1(%Arg%)
         iif(Konto.H2.CurrentMember is .[H2].[All Konto.H2] and Konto.H3.CurrentMember is .[H3].[All Konto.H3] and Konto.H4.CurrentMember is .[H4].[All Konto.H4],%Arg%,Null)
    *endfunction
    *Function Hir2(%Arg%)
         iif(Konto.H1.CurrentMember is .[H1].[All Konto.H1] and Konto.H3.CurrentMember is .[H3].[All Konto.H3] and Konto.H4.CurrentMember is .[H4].[All Konto.H4],%Arg%,Null)
    *endfunction
    *Function Hir3(%Arg%)
         iif(Konto.H1.CurrentMember is .[H1].[All Konto.H1] and Konto.H2.CurrentMember is .[H2].[All Konto.H2] and Konto.H4.CurrentMember is .[H4].[All Konto.H4],%Arg%,Null)
    *endfunction
    *Function Hir4(%Arg%)
         iif(Konto.H1.CurrentMember is .[H1].[All Konto.H1] and Konto.H2.CurrentMember is .[H2].[All Konto.H2] and Konto.H3.CurrentMember is .[H3].[All Konto.H3],%Arg%,Null)
    *endfunction
    *Function ASTxxx_H2(%p1%,%p2%,%p3%)
         iif( .currentmember.name = "YTD", iif( (.[H2].[%p1%],[Measures].[YTD]) = 0, Null,  ( (.[H2].[%p2%],[Measures].[YTD]) / (.[H2].[%p1%],[Measures].[YTD]) ) * %p3% ), iif( .currentmember.name = "M12", iif( (.[H2].[%p1%],[Measures].[M12]) = 0, Null,  ( (.[H2].[%p2%],[Measures].[M12]) / (.[H2].[%p1%],[Measures].[M12]) ) * %p3% ), iif( .currentmember.name = "PERIODIC", iif( (.[H2].[%p1%],[Measures].[PERIODIC]) = 0, Null, ( (.[H2].[%p2%],[Measures].[PERIODIC]) / (.[H2].[%p1%],[Measures].[PERIODIC]) ) * %p3% ), Null))), solve_order=12
    *endfunction
    *Function TotalaIntakter_H2
         (HIR2(.[H2].[AS1000].[H2].[AS1100].[H2].[AS1200].[H2].[AS1300].[H2].[AS1400]))
    *endfunction
    *Function TB1_H2
         (TotalaIntakter_H2+HIR2(.[H2].[AS1500]))     
    *endfunction
    *Function TB2_H2
         (TB1_H2+HIR2(.[H2].[AS1700]))     
    *endfunction
    *Function Totalarorelsekostnader_H2
         (HIR2(.[H2].[AS1500].[H2].[AS1700].[H2].[AS1800].[H2].[AS1810].[H2].[AS1900].[H2].[AS1910].[H2].[AS1930].[H2].[AS1940].[H2].[AS1950].[H2].[AS2000].[H2].[AS2100]))
    *endfunction
    *Function EBITA_H2
         (TotalaIntakter_H2Totalarorelsekostnader_H2HIR2(.[H2].[AS2155]))     
    *endfunction
    *Function EBITDA_H2
         (TotalaIntakter_H2Totalarorelsekostnader_H2HIR2(.[H2].[AS2155]-[KONTO].[H2].[AS2100]))
    *endfunction
    *Function EBIT_H2
         (TotalaIntakter_H2Totalarorelsekostnader_H2(HIR2(.[H2].[AS2155]+.[H2].[AS2185])))
    *endfunction
    *Function Finansnetto_H2
         (HIR2(.[H2].[AS2200]+.[H2].[AS2300]))
    *endfunction
    *Function EBT_H2
         (HIR2(.[H2].[AS1000].[H2].[AS1100].[H2].[AS1200].[H2].[AS1300].[H2].[AS1400].[H2].[AS1500].[H2].[AS1700].[H2].[AS1800].[H2].[AS1810].[H2].[AS1900].[H2].[AS1910].[H2].[AS1930].[H2].[AS1940].[H2].[AS1950].[H2].[AS2000].[H2].[AS2100].[H2].[AS2155].[H2].[AS2185].[H2].[AS2200]+.[H2].[AS2300]))     
    *endfunction
    *Function Netresult_H2
         (HIR2(.[H2].[AS1000].[H2].[AS1100].[H2].[AS1200].[H2].[AS1300].[H2].[AS1400].[H2].[AS1500].[H2].[AS1700].[H2].[AS1800].[H2].[AS1810].[H2].[AS1900].[H2].[AS1910].[H2].[AS1930].[H2].[AS1940].[H2].[AS1950].[H2].[AS2000].[H2].[AS2100].[H2].[AS2155].[H2].[AS2185].[H2].[AS2200].[H2].[AS2300].[H2].[AS2400]))
    *endfunction
    *Function Foradlingsvarde_H2
         (HIR2(.[H2].[AS1000].[H2].[AS1100].[H2].[AS1200].[H2].[AS1300].[H2].[AS1400].[H2].[AS1500].[H2].[AS1700].[H2].[AS1810].[H2].[AS1900].[H2].[AS1910].[H2].[AS1930].[H2].[AS1940].[H2].[AS1950]+.[H2].[AS2000]))
    *endfunction
    *Function Foradlingsvarde_H2_PRO
         (HirPro2(.[H2].[AS1000].[H2].[AS1100].[H2].[AS1200].[H2].[AS1300].[H2].[AS1400].[H2].[AS1500].[H2].[AS1700].[H2].[AS1810].[H2].[AS1900].[H2].[AS1910].[H2].[AS1930].[H2].[AS1940].[H2].[AS1950]+.[H2].[AS2000]))
    *endfunction
    *Function DSO_H2
              iif(((.[H2].[AST610],[Part].[EXT_PART])(.[H2].[AST610],[Part].[PA_None]))=0,Null,((((.[H2].[AS1450],[TimeDim].lag(0),[Part].[EXT_PART],[Measures].[PERIODIC])(.[H2].[AS1450],[TimeDim].lag(0),[Part].[PA_None],[Measures].[PERIODIC])(.[H2].[AS1450],[TimeDim].lag(1),[Part].[EXT_PART],[Measures].[PERIODIC])(.[H2].[AS1450],[TimeDim].lag(1),[Part].[PA_None],[Measures].[PERIODIC])(.[H2].[AS1450],[TimeDim].lag(2),[Part].[EXT_PART],[Measures].[PERIODIC])(.[H2].[AS1450],[TimeDim].lag(2),[Part].[PA_None],[Measures].[PERIODIC]))/3)/((.[H2].[AST610],[Part].[EXT_PART])+(.[H2].[AST610],[Part].[PA_None]))*30))          
    *endfunction
    //Hierarchy 2
    *Function ASTxxxV_H4(%p1%,%p2%,%p3%)
         iif( .currentmember.name = "YTD", iif( (.[H4].[%p1%],[Measures].[YTD]) = 0, Null,  ( (.[H4].[%p2%],[Measures].[YTD]) / (.[H4].[%p1%],[Measures].[YTD]) ) * %p3% ), iif( .currentmember.name = "M12", iif( (.[H4].[%p1%],[Measures].[M12]) = 0, Null,  ( (.[H4].[%p2%],[Measures].[M12]) / (.[H4].[%p1%],[Measures].[M12]) ) * %p3% ), iif( .currentmember.name = "PERIODIC", iif( (.[H4].[%p1%],[Measures].[PERIODIC]) = 0, Null, ( (.[H4].[%p2%],[Measures].[PERIODIC]) / (.[H4].[%p1%],[Measures].[PERIODIC]) ) * %p3% ), Null))), solve_order=12
    *endfunction
    *Function ASTxxxV2_H4(%p1%,%p2%,%p3%,%p4%)
         iif( .currentmember.name = "YTD", iif( (.[H4].[%p1%],[Measures].[YTD]) = 0, Null,  ( ((.[H4].[%p2%],[Measures].[YTD])(.[H4].[%p4%],[Measures].[YTD])) / (.[H4].[%p1%],[Measures].[YTD]) ) * %p3% ), iif( .currentmember.name = "M12", iif( (.[H4].[%p1%],[Measures].[M12]) = 0, Null,  ( ((.[H4].[%p2%],[Measures].[M12])(.[H4].[%p4%],[Measures].[M12])) / (.[H4].[%p1%],[Measures].[M12]) ) * %p3% ), iif( .currentmember.name = "PERIODIC", iif( (.[H4].[%p1%],[Measures].[PERIODIC]) = 0, Null, ( ((.[H4].[%p2%],[Measures].[PERIODIC])+(.[H4].[%p4%],[Measures].[PERIODIC])) / (.[H4].[%p1%],[Measures].[PERIODIC]) ) * %p3% ), Null))), solve_order=12
    *endfunction
    *Function ASTB1_H4
         (HIR4(.[H4].[AS3V]+.[H4].[AS4V])) 
    *endfunction
    *Function ASTB1P_H4
         iif(HIR4(.[H4].[AS3V])=0,Null,ASTB1_H4/HIR4(.[H4].[AS3V])),solve_order=12          
    *endfunction
    *Function ASEBITA_H4
         (ASTB1_H4(HIR4(.[H4].[ASFK].[H4].[ASINTBOLV])))
    *endfunction
    *Function ASEBITAP_H4
         iif(HIR4(.[H4].[AS3V])=0,Null,ASEBITA_H4/HIR4(.[H4].[AS3V])),solve_order=12          
    *endfunction
    *Function ASEBT_H4
         (ASEBITA_H4+(HIR4(.[H4].[AS8V])))  
    *endfunction
    *Function ASEBTP_H4
         iif(HIR4(.[H4].[AS3V])=0,Null,ASEBT_H4/HIR4(.[H4].[AS3V])),solve_order=12          
    *endfunction
    *Function AST902v_H4
         iif(HIR4(.[H4].[AS34V])=0,Null,HIR4(.[H4].[AST001V])/HIR4(.[H4].[AS34V])),solve_order=12          
    *endfunction
    *Function AST907v_H4
         iif((HIR4(.[H4].[AS101v].[H4].[AS35V]))=0,Null,ASEBITA_H4/(HIR4(.[H4].[AS101v])(.[H4].[AS35V]))),solve_order=12          
    *endfunction
    Edited by: Daniel Svensson on Aug 12, 2008 1:29 PM

  • ASO MDX query in outline??????

    Trying to write a MDX query for the Account member
    Hierarchy:
    Account
    A001
    A002
    A003
    A008
    Scenario
    AG00
    AG01
    AG06
    AG08
    AG09
    Organization
    ETCE
    E023
    E024
    E070
    I need to caluculate for the Account AG08 the value should be derived from AG07 and for the same account AG08 for the Organization member "E070" the value should be same as AG09 ( i.e AG09 = AG08 )
    I writen below query at the level "0" retrival query is good but when i use the Top level query "ETCE" parent level the value in "E070" is eliminating . Query writen below
    NONEMPTYMEMBER [A001],[A007]
    CASE
    WHEN (IS([Organization].CurrentMember, [E070])) THEN
    ([A009])
    WHEN (IS([Scenario].CurrentMember, [AG00])) THEN
    (([A007] * -1)/100)
    WHEN (IS([Scenario].CurrentMember, [AG01])) THEN
    (([A007] * -1)/100)
    WHEN (IS([Scenario].CurrentMember, [AG02])) THEN
    (([A007] * -3)/100)
    WHEN (IS([Scenario].CurrentMember, [AG03])) THEN
    (([A007] * -10)/100)
    WHEN (IS([Scenario].CurrentMember, [AG04])) THEN
    (([A007] * -20)/100)
    WHEN (IS([Scenario].CurrentMember, [AG05])) THEN
    (([A007] * -80)/100)
    WHEN (IS([Scenario].CurrentMember, [AG06])) THEN
    ([A007])
    ELSE
    Missing
    END
    At Bottom level "0" results are coming as expected but Its not working at the top level Organization ETCE level Please help ????
    Thanks
    Venu
    Edited by: user13351102 on Oct 28, 2011 5:19 PM
    Edited by: user13351102 on Oct 28, 2011 6:31 PM

    Guru's any help on this ASO Member formula query ??

  • Which is faster -  Member formula or Calculation script?

    Hi,
    I have a very basic question, though I am not sure if there is a definite right or wrong answer.
    To keep the calculation scripts to a minimum, I have put all the calculations in member formula.
    Which is faster - Member formula or calculation scripts? Because, if i am not mistaken, FIX cannot be used in member formulas, so I need to resort to the use of IF, which is not index driven!
    Though in the calculation script,while aggregating members which have member formula, I have tried to FIX as many members as I can.
    What is the best way to optimize member formulas?
    I am using Hyperion Planning and Essbase 11.1.2.1.
    Thanks.

    Re the mostly "free" comment -- if the block is in memory (qualification #1), and the formula is within the block (qualification #2), the the expensive bit was reading the block off of the disk and expanding it into memory. Once that is done, I typically think of the dynamic calcs as free as the amount of data being moved about is very, very, very small. That goes out the window if the formula pulls lots of blocks to value and they get cycled in and out of the cache. Then they are not free and are potentially slower. And yes, I have personally shot myself in the foot with this -- I wrote a calc that did @PRIORS against a bunch of years. It was a dream when I pulled 10 cells. And then I found out that the client had reports that pulled 5,000. Performance when right down the drain at that point. That one was 100% my fault for not forcing the client to show me what they were reporting.
    I think your reference to stored formulas being 10-15% faster than calc script formulas deals with if the Formulas are executed from within the default calc. When the default Calc is used, it precompiles the formulas and handles many two pass calculations in a single pass. Perhaps that is what you are thinking of.^^^I guess that must be it. I think I remember you talking about this technique at one of your Kscope sessions and realizing that I had never tried that approach. Isn't there something funky about not being able to turn off the default calc if a user has calc access? I sort of thing so. I typically assing a ; to the default calc so it can't do anything.
    Regards,
    Cameron Lackpour

Maybe you are looking for