Copying values from a element to attributes

[DNA_DC]

I have an element (Sponsor) in my measures that will be populated by string data through a process. I want to populate the data that comes in there into an attribute (also called "sponsors") in another dimension (called "Organizations"). I want to use that attribute to develop a dynamic subset to allow my users to see the "Organization" by "Sponsor".

All help would be greatly appreciated!

[Martin Ryan]

Are you using TI? The function you need is attrputs(value, dimension, element, attribute). If you're using Excel then you need DBSA(value, server:dimension, element, attribute).

Cheers,
Martin

[DNA_DC]

I want to copy all of the values from that element to the attribute... will I have to write that for every value?

[Martin Ryan]

Quickest way is to create a view that has all the data you want then snapshot it out into Excel and use a DBSA to load it all back up as attributes. DBSA are like any Excel formula and can be copied and pasted if you have relative references, so this'll be pretty quick.

Martin

[DNA_DC]

Interesting... a follow up then, instead of pushing the value from an element to the attribute, tried to load the element value from the attribute, would that be easier?

[Martin Ryan]

You could write a rule:
['Sponsorship'] = S: attrs('Organizations', !Organizations, 'Sponsor');

What are you trying to achieve? Capturing the data twice is (usually) redundant, you can report attributes in your reports if you wish, so there's no need for it to be stored in the cube. In general it's common practice to avoid putting string data in cubes where possible.

Martin

[DNA_DC]

You could write a rule:
['Sponsorship'] = S: attrs('Organizations', !Organizations, 'Sponsor');

What are you trying to achieve? Capturing the data twice is (usually) redundant, you can report attributes in your reports if you wish, so there's no need for it to be stored in the cube. In general it's common practice to avoid putting string data in cubes where possible.

Martin

Brilliant! Unfortunately, the boat has long passed on that best practice on this project.

Another rookie question for you, Sensei.

What would the feeder statement for that look like? I tried the following:

['Organizations', !Organizations, 'Sponsor'] => ['Sponsorship'];

but something tells me I'm wayy off.

[Martin Ryan]

Oh, hmm. Yeah. Another reason why strings aren't recommended, feeding them is a pain in the whats-it.

You need to go into the attributes cube and feed from there and you'll have massive overfeeding because the attribute cube is two dimensional, whereas your other cube probably has half a dozen or so.

You'll need to use FeedStrings; I'm not sure if that needs to go in the source cube, destination cube, or both. The manual should tell you. The feeder will be something like the below where 'All Dim1' is a consolidation of all your elements in Dim 1. This will lead to serious overfeeding and a huge performance degredation, so use at your own risk.

['Sponsor'] => DB('Cube to use', 'All Dim1', 'All Dim2', !Organization, 'All Dim4');

Rules is starting to look like a really bad option. If you need to update this on a regular basis you're probably better to write a TI process that zips through and writes the values into the cube.

Martin

[DNA_DC]

Yeah... it really is... I might try to add this to the existing "load" process. Where it will add it to both the attribute in the other dimension AND the element in the measure dimension.