Enterprise Transformations, It's all About Performance Management

There are times when we need to delete all the Alias, Descriptions, Formulas, UDAs, Smart Lists, or Attribute Binding etc. from an existing planning application. All these requirements are achievable, if you want to do it at once one of the options is: our good old Outline Load utility. In such scenarios "<NONE>" is your best companion! While loading members all we need to do is to add <NONE>  in the required column, this will remove all the existing associations and values. Let's take a scenario, as a last minute requirement your client needs cross tab reporting, your solution architect has decided to use Attributes instead of UDAs, as  repercussions you need to delete all the UDAs, change all the calcs etc. Now, in order to delete all UDAs you can: 1. Go to each member and delete UDA,  2. Go to relational database and do some unsupported background changes,  3. Use LCM, 4. Use the Outline Load utility, Here, we will be discussion

The FIX…ENDFIX command block restricts database calculations to a subset of the database. All commands nested between the FIX and ENDFIX statements are restricted to the specified database subset. What I know about FIX is, it takes the union of the members which are in different FIX or (Hypothetically) are repeated in the same fix, so even if you mention FIX("E1","E1","E1") it will work on "E1" and just once, not thrice! . Say you have fully populated data cube and you need to delete the data for one Entity(say E1), the fastest thing you will probably write is: FIX(@REMOVE(@RELATIVE("Entity",0), "E1")   CLEARBLOCK ALL; ENDFIX Yes, its done! This will remove the data for all the level 0 entities but not for E1. This will happen assuming there is no alternate hierarchy. ------------------------------------------------------------------------------------------------------------ Lets go in detail: the

Most of the times we have to refer data from one cube to another. There are many ways in which you can transfer or refer data from a cube, few  of the most popular ways are: 1. Create a partition, 2. Create a XREF, 3. Create an export and import script, etc. Every way has its own pros and cons. Today our discussion will be focused on XREF. Trust me if you are working with Planning applications you are dealing with XREFs all the time. If there is a  planning application with multiple plan types, Planning automatically creates the XREFs between cubes for the members. If we have a planning application with two plan types, say REV and INCSTMT and we have a stored member say "OtherRevs". Let's say this member has the source plan type as REV and its enabled for both the PlanTypes. In this case Planning will create this member in both the cubes, however in REV cube it will be a stored member but in INCSTMT it will be a dynamic calc member with an auto generated XREF. Th