same cube with 2 differents dimensions

[pobrouwers]

hello,

I Have 2 cubes and I have 2 dimension's products :
First dimension for exemple "products" is :
Total
Familly A
SKU1
Familly B
SKU 2

The second dimension for exemple "products_bis" is
Total
Familly A
Familly B

How create a rule to get values for each Familly in the cube2?
In my rules for cube2

Code: Select all

[Volume] = N:DB('cube1',!products_bis','Volume');

This rules doesn't work because I have 2 differents dimension "product" and I use "!"
How do you make ?
Thx in advance

Piet

[Mike L]

Is the problem just an extra apostrophe?

Code: Select all

[Volume] = N:DB('cube1',!products_bis,'Volume');

[mattgoff]

Bracket notation allows arbitrary element order, but you can specify dimension names. In fact, I've gotten into the habit of explicitly defining the dimension for each element as I've had problems in the past where a rule compiled but was later made ambiguous when I added an element to a dimension. The syntax is:

[dim1:'element1', dim2:'element1'] = N: ...

However, unless I'm misreading your example, you don't have duplicate element names in different dimensions in the same cube, so this ambiguity isn't possible. As Mike said, it looks like you've got some apostrophe issues. Does this work?

['volume'] = N: DB('cube1',!products_bis,'volume');

If not, more info (instead of the hypothetical) would be helpful.

Matt

[pobrouwers]

Hello,

In fact, I had got some apostrophe issues . This is a mistake of my part.
I wanted to say :
['volume'] = N: DB('cube1',!products_bis,'volume'); but it doesn't work !

Because products_bis is not in the cube1.
I believe when we use the expression "!dim", this dim must be present into the 2 cubes. Isn't it ?

How to tell him he must match "products" and "products_bis" on all elements ?

I am sure that this is possible, but unfortunately I don't know the syntax

Thx

[David Usherwood]

If you want to link cubes with different, but related dimensions, then use the dimension in the cube in which the rule is written. In your case

['volume'] = N: DB('cube1',!products,'volume');

will pull across values where the products dimension matches the products_bis dimension.

BUT....

Watch out for feeders. You can write a similar feeder eg
['Volume'] => DB('cube2',!products_bis,'volume');
and it will compile fine - but feeders _only_ work at N level. If the N level in products_bis match the N level in products, fine. If not (which is common), you need to link the two dimensions, typically via an attribute on products_bis which delivers the matching products. You can also feed to a specific high level destination but that is likely to be a big feeder.

HTH

[Mike L]

I believe when we use the expression "!dim", this dim must be present into the 2 cubes. Isn't it ?
How to tell him he must match "products" and "products_bis" on all elements ?

No, it should just work. The values of a !dim variable are the names of the dimension elements. If the rule is in cube2 which uses dimension "products_bis", and if all of the N elements of "products_bis" correspond to identically named elements in the (larger) "products" dimension used by cube1, your syntax should work.

One common mistake: Does the DB() include elements for every dimension of cube1, in the right order?

What is the symptom of not working? Does it fail to compile and save? Does it save but not produce expected results? Any error message?

[Mike L]

Watch out for feeders.

Yes, always watch out for feeders. But it is worth noting that when using rules to populate a summary cube, if the summary is not sparse (often, but not always the case) then there is little to be gained from SKIPCHECK so you may be able to dispense with feeding altogether.

(That is, the only thing to be gained is avoiding the suppress-zero bug if for some reason you happen to suppress on a non-sparse cube.)

[John Hobson]

(That is, the only thing to be gained is avoiding the suppress-zero bug if for some reason you happen to suppress on a non-sparse cube.)

And of course the related inaccurate / unpredictable ascii export of calculations in a non-skipchecked / fed cube. (raised yonks ago, but not a big enough problem to have been fixed)

[pobrouwers]

Hello.
Thank you David. It's work....