Showing posts with label attribute. Show all posts
Showing posts with label attribute. Show all posts

Tuesday, March 27, 2012

Calculated Member - #VALUE! in the Grand Total

Hi all

This is a simple question on MDX.

We have created a calcualted member that basically compares an existing measure to an attribute, and displays a certain value based on what's in the attribute (simple case statement)

The calcualtion works fine against the proper dimension, but for Grand Total displays #VALUE!. What do I have to do to make the grand total actually display a grand total of this calculated member in the cube?

Thanks in advance

Moe

Hi Moe,

Can you give an idea of what the MDX for the calculated member looks like?

|||

Hi Deepak

Here's the code for the calculated member. Please let me know if you need anything else.

CREATE MEMBER CURRENTCUBE.[MEASURES].[calc - Spare Cost]

AS case when [Repairs].[Repair Status].&[Done] then [Measures].[ARC Buy Price]

when [Repairs].[Repair Status].&[Not Done] then 0

else -1 end,

FORMAT_STRING = "#",

NON_EMPTY_BEHAVIOR = { [ARC Buy Price] },

VISIBLE = 1;

|||

If the intent is to return the value of [Measures].[ARC Buy Price] associated with the [Repairs].[Repair Status].&[Done] member, maybe something simpler like this will work:

CREATE MEMBER CURRENTCUBE.[MEASURES].[calc - Spare Cost]

AS iif([Repairs].[Repair Status].CurrentMember is [Repairs].[Repair Status].&[Not Done],

0, ([Repairs].[Repair Status].&[Done], [Measures].[ARC Buy Price])),

FORMAT_STRING = "#",

NON_EMPTY_BEHAVIOR = { [ARC Buy Price] },

VISIBLE = 1;

|||

Hi Deepak

Thanks for the reply.

The code sample you sent me gives me a value in the Grand Total now, but I am confused as to what this Grand Total actually is .

To simplify my problem, I created the following example based on Northwind:

CALCULATE;

CREATE MEMBER CURRENTCUBE.[MEASURES].[Calculated Member]

AS iif(

[Orders].[Customer ID].CurrentMember = [CHOPS], 5, 1),

FORMAT_STRING = "#",

NON_EMPTY_BEHAVIOR = { [Orders Count] },

VISIBLE = 1 ;

The above code gives me a Grand Total of 1! is this correct?

Thanks again

Moe

|||

Hi Moe,

I'm not clear how to run your sample code - could you provide an Adventure Works equivalent? Also, what should your results layout look like - and how many members of [Repairs].[Repair Status] are there (I assumed that there are just 2)?

Sunday, March 25, 2012

calculated measure

I have a cube with a project dimension:

User Hierarchy

Project.ProjectHierarchy

Project.GrowthPlatform

Project.Stream

Project.ProjectName

Attribute

Project.GrowthPlatform

Project.Stream

Project.ProjectName

I would create a calculated measure that is

meas1 * (meas2 / meas3) only for th ProjectName level (the lowest)

Sum(children) for the other level

How can I test the level of a dimension ?

Cosimo

IIF(Project.ProjectHierarchy.CurrentMember.Level IS Project.ProjectHierarchy.ProjectName, ...)|||

Hi,

I would try to use the SCOPE function instead of the IIF. Sometning like this should work:

SCOPE([Project].[ProjectHierarchy].[ProjectName].members,[Project].[ProjectName].members);

-- Insert calculated measure here

END SCOPE;

HTH,

Eric

|||

Thanks for the suggestion.

I'm quite new of SSAS 2005 and had some experience in AS 2000.

In AS 2000 you can do [dimension].CurrentMember ... but in SSAS 2005 every attribute is a hierarchy so I need to do [dimension].[hierarchy].CurrentMember. But I need a solution for all the hierarchyes !

So I partially solved the problem for [PROJECT].[STREAM] using the he following formula:

IIF ([PROJECT].[STREAM].CURRENTMEMBER.LEVEL_NUMBER = 0

, SUM ( [PROJECT].[STREAM].CURRENTMEMBER.CHILDREN, [Measures].[NUM HEADCOUNT SUBCO] * [Measures].[NUM FTE NO SUBCO] / [Measures].[NUM HEADCOUNT NO SUBCO] )

,[Measures].[NUM HEADCOUNT SUBCO] * [Measures].[NUM FTE NO SUBCO] / [Measures].[NUM HEADCOUNT NO SUBCO]

)

But this does not function the other hierarchy.

There is a way that can function for all the hierarchy ...

What I really need is ussing the ratio only for the lowest level [PROJECT].[PROJECT NAME] and using the sum of the children for all the others.

Cosimo

|||

I solved the problem defining four different calcolated measures, even if it could be interesting having just one calculated measure that functions for all the hierarchies.

Cosimo

Calculated Fields

When you use the FORMULA attribute for a column in EM does SQL Server
actually store the "calculated" data or just materialize it when it's
fetched ?
TIA
Liz
Liz wrote:
> When you use the FORMULA attribute for a column in EM does SQL Server
> actually store the "calculated" data or just materialize it when it's
> fetched ?
> TIA
> Liz
The value is not permanently stored unlesss you create an index on the
computed column. For that reason computed columns in tables are of
little value unless you intend to index them.
If you try to update a computed column directly you will get an error.
That's why for most purposes I think it is safer and makes the meaning
clearer if you put computations into views rather than tables. Views
can be indexed too, so I would only consider a computed column where an
indexed view or some other method couldn't achieve the same purpose.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
|||"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1166266554.326117.237240@.16g2000cwy.googlegro ups.com...
> Liz wrote:
> The value is not permanently stored unlesss you create an index on the
> computed column. For that reason computed columns in tables are of
> little value unless you intend to index them.
I tried it out because I'm working with a table that has incredibly bizarre
column names so it just makes it easier to reference a+b+c as MYFIELD ... I
did index the calculated column and then had a brief glitch; a row which
should have matched did not ... then the problem "went away" ... which makes
me uneasy. If the "underlying" columns are indexed does the "calculated
column" effectively "use" the index ? I guess I can look at an execution
plan and find out ...
Thanks,
Liz

> If you try to update a computed column directly you will get an error.
> That's why for most purposes I think it is safer and makes the meaning
> clearer if you put computations into views rather than tables. Views
> can be indexed too, so I would only consider a computed column where an
> indexed view or some other method couldn't achieve the same purpose.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>
|||Calculated fields are 'calculated' upon request. The data is not
materialized. (There is a way, however, involving indexing... But that is
not 'normal'.)
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
You can't help someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf
"Liz" <liz@.tiredofspam.com> wrote in message
news:OeszSGNIHHA.2632@.TK2MSFTNGP06.phx.gbl...
> When you use the FORMULA attribute for a column in EM does SQL Server
> actually store the "calculated" data or just materialize it when it's
> fetched ?
> TIA
> Liz
>

Calculated Fields

When you use the FORMULA attribute for a column in EM does SQL Server
actually store the "calculated" data or just materialize it when it's
fetched ?
TIA
LizLiz wrote:
> When you use the FORMULA attribute for a column in EM does SQL Server
> actually store the "calculated" data or just materialize it when it's
> fetched ?
> TIA
> Liz
The value is not permanently stored unlesss you create an index on the
computed column. For that reason computed columns in tables are of
little value unless you intend to index them.
If you try to update a computed column directly you will get an error.
That's why for most purposes I think it is safer and makes the meaning
clearer if you put computations into views rather than tables. Views
can be indexed too, so I would only consider a computed column where an
indexed view or some other method couldn't achieve the same purpose.
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1166266554.326117.237240@.16g2000cwy.googlegroups.com...
> Liz wrote:
>> When you use the FORMULA attribute for a column in EM does SQL Server
>> actually store the "calculated" data or just materialize it when it's
>> fetched ?
>> TIA
>> Liz
> The value is not permanently stored unlesss you create an index on the
> computed column. For that reason computed columns in tables are of
> little value unless you intend to index them.
I tried it out because I'm working with a table that has incredibly bizarre
column names so it just makes it easier to reference a+b+c as MYFIELD ... I
did index the calculated column and then had a brief glitch; a row which
should have matched did not ... then the problem "went away" ... which makes
me uneasy. If the "underlying" columns are indexed does the "calculated
column" effectively "use" the index ? I guess I can look at an execution
plan and find out ...
Thanks,
Liz
> If you try to update a computed column directly you will get an error.
> That's why for most purposes I think it is safer and makes the meaning
> clearer if you put computations into views rather than tables. Views
> can be indexed too, so I would only consider a computed column where an
> indexed view or some other method couldn't achieve the same purpose.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>|||Calculated fields are 'calculated' upon request. The data is not
materialized. (There is a way, however, involving indexing... But that is
not 'normal'.)
--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
You can't help someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf
"Liz" <liz@.tiredofspam.com> wrote in message
news:OeszSGNIHHA.2632@.TK2MSFTNGP06.phx.gbl...
> When you use the FORMULA attribute for a column in EM does SQL Server
> actually store the "calculated" data or just materialize it when it's
> fetched ?
> TIA
> Liz
>

Calculated Fields

When you use the FORMULA attribute for a column in EM does SQL Server
actually store the "calculated" data or just materialize it when it's
fetched ?
TIA
LizLiz wrote:
> When you use the FORMULA attribute for a column in EM does SQL Server
> actually store the "calculated" data or just materialize it when it's
> fetched ?
> TIA
> Liz
The value is not permanently stored unlesss you create an index on the
computed column. For that reason computed columns in tables are of
little value unless you intend to index them.
If you try to update a computed column directly you will get an error.
That's why for most purposes I think it is safer and makes the meaning
clearer if you put computations into views rather than tables. Views
can be indexed too, so I would only consider a computed column where an
indexed view or some other method couldn't achieve the same purpose.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1166266554.326117.237240@.16g2000cwy.googlegroups.com...
> Liz wrote:
> The value is not permanently stored unlesss you create an index on the
> computed column. For that reason computed columns in tables are of
> little value unless you intend to index them.
I tried it out because I'm working with a table that has incredibly bizarre
column names so it just makes it easier to reference a+b+c as MYFIELD ... I
did index the calculated column and then had a brief glitch; a row which
should have matched did not ... then the problem "went away" ... which makes
me uneasy. If the "underlying" columns are indexed does the "calculated
column" effectively "use" the index ? I guess I can look at an execution
plan and find out ...
Thanks,
Liz

> If you try to update a computed column directly you will get an error.
> That's why for most purposes I think it is safer and makes the meaning
> clearer if you put computations into views rather than tables. Views
> can be indexed too, so I would only consider a computed column where an
> indexed view or some other method couldn't achieve the same purpose.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>|||Calculated fields are 'calculated' upon request. The data is not
materialized. (There is a way, however, involving indexing... But that is
not 'normal'.)
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
You can't help someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf
"Liz" <liz@.tiredofspam.com> wrote in message
news:OeszSGNIHHA.2632@.TK2MSFTNGP06.phx.gbl...
> When you use the FORMULA attribute for a column in EM does SQL Server
> actually store the "calculated" data or just materialize it when it's
> fetched ?
> TIA
> Liz
>

Calculated field with Percent

Hi,

I have a calculated field with percent format. However, the value of this field aggregates at every attribute i place on the browser. i want only to show this calculated field in the detail cell on. if the user tries to roll up, i must not be able to see any data in it.

Example

Problem: (View 1)

Service Job Discount Amount

1 200% 3000

2 40% 500

3 100% 400

As i drag the line number to the browser, i saw the right discount value:

(View 2)

Service Job LineNumber Discount Amount

1 1 100% 1500

1 2 100% 1500

2 1 40% 500

3 1 60% 100

3 1 40% 300

How can I make the discount blank on View 1 and only exists if i drag the line number? The problem in View 1 is it sums up the discount which is wrong.

cherriesh

Check whether you are in the right level:

CASE WHEN
[Dimension].CurrentMember.Level.Ordinal > 0
THEN [Measures].[Discount]
ELSE
NULL
END

More info and better recommendations here:
http://www.mosha.com/msolap/articles/mdxcomparinglevels.htm

Hope that helps,
Ibrahim

Thursday, March 22, 2012

Calculated Dimension Member destoys date-hierarchy structure

Hi, I have a problem if I add a Calculated Dimension Member to a Date Hierarchy,

first I thought - I would set attribute relationship of my date-dimension not properly,

but then I tried to apply this to AW-DataBase.

Here's a script of creating Calculated Member in AW (Date.Calendar):

CREATE MEMBER CURRENTCUBE.[Date].[Calendar].[All Periods].[DateCalcMember_CopyOf2004]
AS [Date].[Calendar].[Calendar Year].&[2004],
VISIBLE = 1 ;

After adding it, try to expand the years-nodes in browser: you won't find any semesters behind,

except CY2001 - he got all semesters of other as childs.

It is possible to configure this behaviour somewhere or it is a bug of OWC 11 PivotTable that is used

in Cube Browser?

Thank you in advanced for your answers.

Regards, Mastroyani

Hi Mastroyani. Your problem definition is not 100% clear, so I made an assumption. The assumption is the problem definition which is, "after adding the calculated member and browsing the dimension in the cube browser the only member which shows the half-year members ([H1 CY 2002], [H2 CY 2002], etc.) is the [CY 2001] member." You can isolate where the problem lies by using another tool such as the SQL Server 2005 Manager to issue a separate MDX query outside onf the Cube Browser. Below is an MDX query using your same definition for [DateCalcMember_CopyOf2004]. You can see from the results that the member [CY 2004] shows it's own half-year children. Perhaps you are seeing an error with the cube browser?

Hope this helps - Paul Goldy

WITH MEMBER [Date].[Calendar].[All Periods].[DateCalcMember_CopyOf2004]
AS '[Date].[Calendar].[Calendar Year].&[2004]'

SELECT
{[Measures].[Internet Sales Amount]} ON COLUMNS
,{[Date].[Calendar].[Calendar Year].&[2004]
,[Date].[Calendar].[Calendar Year].&[2004].Children
,[Date].[Calendar].[All Periods].[DateCalcMember_CopyOf2004]} ON ROWS
FROM [Adventure Works]

===== Results

Internet Sales Amount
CY 2004 $9,770,899.74
H1 CY 2004 $9,720,059.11
H2 CY 2004 $50,840.63
DateCalcMember_CopyOf2004 $9,770,899.74

|||Hi, I have exactly the same problem. Have anybody figured out the problem?

thanks
Hank