Rolevalue Function

[srinu1253]

Can I know why this Function is used.Is it used for Member or Memberset?
Can any one tell the differece betwee member and memberset??

[CognosPaul]

The rolevalue function will return a string containing the desired property of the referenced member. While I have no experience with DMR (won't touch the stuff), it may have some use in FM. For the most part when I do need to use it, I use it in RS.

You most commonly use the rolevalue function without realizing it. Whenever you run the caption function, for example caption([Sales (analysis)].[Order].[Order].[Order(All)]->[all]) Cognos really runs the function rolevalue('_memberCaption',[Sales (analysis)].[Order].[Order].[Order(All)]->[all]).

You can see exactly what properties you can use for a specific member by right-clicking the member in the available components window. The format to use is _firstSecondThirdFourth. It always begins with an underscore, the first word being lowercase with the first letter of every additional word capitalized. So rolevalue('_ref',[Sales (analysis)].[Order].[Order].[Order(All)]->[all]) for the Ref property and rolevalue('_dimensionUniqueName',[Sales (analysis)].[Order].[Order].[Order(All)]->[all]) for the dimension unique name.

I use it mostly to find the category code of a specific member, or to find the level number (instead of doing ordinal(level([member]))).

I'm running out of time so I'll let someone else explain the difference between members and sets.

[blom0344]

While I have no experience with DMR (won't touch the stuff)

Would be my first inclination too. But Paul, could you share your hesitations  with regards to DMR? Some of my collegues expect everything from it   ;D

[CognosPaul]

Where to begin...

Let me begin with this:
I am not a Framework expert. I've pretty much abandoned framework since I've learned to use cubes. However, whenever I do build any framework model there are a few basic guidelines that I always adhere to.

1. Foresight. One of the most important jobs of a modeler is to ensure that every query the user can create is correct, obeys the index, and makes sense in the context of the report. The modeler needs to anticipate the way the model will be used and mold it around the limitations of the database. ¹

2. Speed. As long as the SQL is correct, the indexes are obeyed and the proper filters are used there is no reason for a query to take an exorbitant amount of time. 

3. Elegance. There is no need for anyone to get lost digging in a model with even a few hundred tables. As long as the tables are logically grouped in the data layer, and the presentation and business layers are set up correctly, any person with even a minimal level of training should be able to look at it and understand what's going on. This is not to say it should be simple. Macros are hardly simple, but are much faster than, for instance, using a case when statement.


First and foremost, what everyone seems to forget, is that DMR is still on top of a standard relational database. Every dimensional function simply bloats the SQL to an insane degree. For an easy explanation of why I never use DMR all you need to do is view the generated SQL. If there is a problem in the framework, finding it through the generated SQL will be a nightmare. Additionally, depending on the order of a tuple it may or may not obey the index². The SQL behind tuple([Measure],[Item1],[Item2]) is different from tuple([Item2],[Item1],[Measure]) even though the result should be identical.

Secondly is the practical matter. Despite it's apparent dimensional qualities there are still some things you can simply not do with DMR. I've heard of problems with sorting sets, using the except function will cause a performance drop. You are actually encouraged to use detail filters with DMR.

Many to Many. This deserves its own 3 hour lecture with slides and handouts, followed by workshops and a complementary lunch.

Finally you can compare DMR to using a real cube. In a real cube the data is already compiled, meaning that if you build the query correctly the results should be returned almost instantly. Naturally all of the dimensional functions work. The Many to Many problem disappears entirely. Depending on the technology, powercubes³ vs SSAS⁴, you can many attributes to work with.

The bottom line is that DMR is only good for giving a very basic example of why everyone should start using real cubes. The functionality is limited, performance is poor, debugging can be close to impossible, and with the effort involved you'd might as well go the next step and use a powercube.

1: The modeler should be on a first name basis with the DBA and, depending on his professionalism, always have an emergency bottle of Finlandia on hand.
2: A good example of use of bribery. Traces are so much easier to get when you don't submit a request a week in advance.
3: Boooo
4: Yay!

[IceTea]

Thanks PaulM for your statement.

Actually, we do DMR in FM and use the DMR Objects in Transformer for building cubes (you can import them). What do you think about this approach?

[CognosPaul]

I'll admit it, I'm very uncomfortable answering this. In every single project that I've worked on I've always pushed the clients away from DMR. I guess as long as the data is compiling correctly, and your reports are running against an actual cube it should be okay.

[blom0344]

Paul, I very much appreciate your contribution.. We are evaluating the switch from Powercubes to DMR, but I feel neither solution will be optimal. The traditional cube involves a lot a fiddling (yes, like cubeswap utility) and DMR may be too much of a compromise.
Somewhere in the middle we expect TM1 and we sure want to find out if that is going to suit us..

[CognosPaul]

Have you considered making the jump to SSAS? It is a major investment, but ultimately worth it. My experience is limited more to the report development side, but from what I've seen both modifying and updating the cube is very easy.