If you are unable to create a new account, please email support@bspsoftware.com

 

News:

MetaManager - Administrative Tools for IBM Cognos
Pricing starting at $2,100
Download Now    Learn More

Main Menu

Linking detail to summary data with SKIPCHECK on

Started by DavidSmith, 15 Jul 2010 07:05:58 AM

Previous topic - Next topic

DavidSmith

I have sucessfully worked out how to transfer data from a detail cube to  a summary cube which have different dimensions but the same element name. However, once SKIPCHECK is turned on in the target cube I can't get the feeder statement to work

For example:
Sales3 cube has a Subs dimension with site1, site2 etc rolling up to Area 1, Area 2 etc

Regions cube has the same dimensions but replaces Subs with Regions with Area1, Area 2 etc

The rule in Regions is:
['Quantity']=N:DB('Sales3',!Channels,!Months,'Quantity',!Regions,!Versions);
With SKIPCHECK off this works fine

With SKIPCHECK on I have to put a FEEDER in the Sales3 cube:
['Quantity']=>DB('Regions',!Months,!Subs,!Versions,!Channels,'Quantity');

The source data cube is purely data enter no other rules

The rules all save OK but no data comes through at Consolidated level

Help!
David

dusherwo

I believe this is now documented in the Rules Help documentation - it used not to be.
Feeders only work at N level. If you write a feeder from (and/or to) a C level, it is translated into a (potentially very big) feeder from all the ultimate descendants of that C level element.
So your feeder to !Subs will try to match your base level sites to regions in the destination dimension, and fail silently.
The safest way to deal with this is to create an attribute of !Subs holding the relevant !Regions element and use that for the feeder. It's a bit of maintenance but not much.
An alternative is to feed to the parent of !Subs using elpar - but that will fail unless there is exactly _one_ parent of each n level !Subs.

Good luck and welcome to the wicky wacky world of feeders. They work well once you get your head round them.

DavidSmith

Many thanks for the reply

A bit confused though, as the example in the rules guide (Chapter 6) did take consolidated values across into another cube, and the screen shots example shows it with skipcheck:

Anyway I tried with the elpar as below and it works, although I didn't do anything with attributes

['Quantity']=>DB('Regions',ELPAR('Subs',!Subs,0),'Quantity');

Can you just tell me if that's going to be OK - I'm not sure about the 0 parameter I have between 1 and 4 children rolling up into regions and every region does exisit in the Subs hierarchy

Cheers
David

OLAPBPMguy

ElPar('Dim', !Dim, 0) is incorrect.  The last argument needs to refer to the index of the parent that the element rolls up to (eg. 1st parent, 2nd parent etc.)  As which parent is the 1st versus second can be variable and subject to change when dimension structure changes it is generally better not to ever use ElPar in rules.  It is much better to define an attribute for this purpose.

There is already A LOT of discussion on this topic elsewhere.  I suggest you look at olapforums then search for "feeders".

DavidSmith

Thanks for the reply

However, I'm a bit confused. The link does work (is this a fluke!)

Also on the training course we used ELPAR to populate a control cube with currencies

Cheers
David

OLAPBPMguy

Quote from: DavidSmith on 23 Jul 2010 10:28:14 AM
Thanks for the reply

However, I'm a bit confused. The link does work (is this a fluke!)

Also on the training course we used ELPAR to populate a control cube with currencies
What you do on a training course has precious little bearing on real world application and even less on real world best practice.  If you go to the other forum you will see lots of content and discussion on this.

DavidSmith

Yeah, appreciate that

Do you have a link to the other forum you refer to?

cheers