Database Reference
In-Depth Information
all the member calculations that were in the BSo cube (Demo). oh, that all of your
calculations (and mine) were this easy to convert. I know when I was first learning and
writing mDx code, the network 54 Essbase message board (http://www.network54.com/
Forum/58296/) was a priceless tool and kept me sane. I asked a lot of questions on how to
convert various BSo calculations to their ASo counterparts. As we continue this chapter,
we will assume the calculations are now coded in mDx. Determining Solve order is the
next task we want to focus on as we get close to completing the conversion process.
5.3.3 Determining Solve Order
Simply put, in the context of a member calculation within the outline, the solve order is
a mathematical assignment from 0 to 127 that we assign a member in the outline. This
assignment determines the order in which the cube will execute the member calculation
at report run-time, and takes into account all members involved in the query process.
Custom Solve orders also can be added to mDx queries. This chapter is not address-
ing that particular usage of Solve orders. Solve order was always the feature I wished
I had in a BSo cube. As you know, in BSo cubes calculation orders are determined by
rules within Essbase—looking at a combination of dimension and member tags, Sparse
and Dense Designations, and the order of the outline. you had to watch carefully to
make sure you avoided “Forward Calculation references.” understanding it, especially
when you had a calculation issue, could become complex. The DBAg dedicates dozens
of pages to making sure you understand these rules and complexities. Inevitably, the
thing that would make you crazy was the total inability to control it all in a simple man-
ner. Working within the confines of the “rules” to manipulate the outline and members
was the best that you could accomplish.
In sharp contrast, this is a very neat and tidy process in an ASo cube. once you have
added the calculation to a member in the outline, right click on the member and go to
Edit member Properties. The last selection under the type section is to input the desired
solve order. The higher the number, the later the calculation occurs during the run-time
process of the report. A 1 would happen after all the defaults (0s), then a 2 would execute
next, and so on. typically, developers will add these in increments of 5 so if you need to
insert one you do not have to renumber everything to which you have already assigned
a solve order in a specific sequence. After typing in the number (let's pretend we assign
a 5), click ok and you should now be able to see the assigned solve order in the outline.
It will typically look like this:
MemberName (+) [5: [Dim].[Member1]-[Dim].[Member2]]
you can use this as soon as the outline has been saved. This change will cause a
restructure to occur so beware of the fact that a fully loaded and aggregated cube could
restructure for a lengthy amount of time. I have a very large ASo cube that this type of
change would launch a 60 to 90 minute restructure process. Assuming that your initial
changes are made to an empty cube, this should not be an issue at the start.
“When do I need a solve order?” For sure, any member in your BSo cube that was tagged
as two-pass will most likely need a solve order added to it. For the most part, you just need
to think through your calculations and dependencies. If I had the following scenario:
MemberA - Loaded
MemberB - Loaded
MemberC - Loaded
Search WWH ::




Custom Search