DimensionElementComponent behaviour

[mnaithan]

Hello

I have seen two way of adding an element to consolidation:
a)
DimensionElementInsert():
DimensionElementComponentAdd()

b) just DimensionElementComponentAdd()

In the first approach first we add element to dimension and then to component and in 2nd one we directly add into component

I am just wondering whats the difference b/w two and is there any preferred method then another, my doubt is what is the need of adding element first to Dim and then to Consolidation if we can add directly in Consolidation (which will add element to Dim as well)

[declanr]

All down to personal preference; as you have found dimensionelementcomponentadd will automatically create the element first if it does not already exist so you get the same end result.

My preference is to just use the componentadd as it is one less line of code and I find it neater but that is just my choice. I know others who prefer to do an insert first as they find it easier to follow when explicitly stating in logic what is happening step by step.

[mnaithan]

Thanks for clarification Declan, even I prefer DimensionElementComponentAdd but was just wondering if I might be missing something

Regards

Micy

[Alan Kirk]

Thanks for clarification Declan, even I prefer DimensionElementComponentAdd but was just wondering if I might be missing something

One thing (and it may or may not be important depending on the circumstances) is that DimensionElementInsert gives you more control over where the element is inserted via the InsertionPoint argument. It can matter if order is important and/or if you have multiple hierarchies.

Personally I fall into the other class of people that Declan mentioned; I use it to make the code more self-documenting to anyone who reads it later,

[mnaithan]

Thanks Alan, make sense, insertion point preference is worth considering

Regards

Micky

[TrevorGoss]

What about the direct functions? Such as DimensionElementInsertDirect and DimensionElementComponentAddDirect? Would you prefer to use these? Should we stay away from them? When is it best to use them?

I have looked at the documentation http://www.ibm.com/support/knowledgecen ... ons_N71607 but I would like other opinions.

Thanks

[Wim Gielis]

And let me add another related topic...

When using DimensionElementInsert, we don't get an error when the element already exists.
When using DimensionElementInsert, we get an error when the element already exists as an alias.

So, do people wrap this DimensionElementInsert statement into a statement with If( Dimix( ) = 0 ) ?

[Alan Kirk]

What about the direct functions? Such as DimensionElementInsertDirect and DimensionElementComponentAddDirect? Would you prefer to use these? Should we stay away from them? When is it best to use them?

I have looked at the documentation http://www.ibm.com/support/knowledgecen ... ons_N71607 but I would like other opinions.

For mine the direct functions are best suited to single updates... which I rarely do. Mostly I run updates of potentially dozens or tens of dozens of items. At present at least I'd therefore rather stick with the existing process of creating a copy in memory, fully updating the copy, checking it for consistency, then boom, one update, one time. However I'm not wedded to it. And with the RESTful API being stateless, that will probably eventually become the less common way of doing it (though it won't be obvious to us from the front end).

And let me add another related topic...

When using DimensionElementInsert, we don't get an error when the element already exists.
When using DimensionElementInsert, we get an error when the element already exists as an alias.

So, do people wrap this DimensionElementInsert statement into a statement with If( Dimix( ) = 0 ) ?

I prefer to regulate my aliases (and possibly my primary names) so that I don't run that risk in the first place. Normally (except for things like dates and times) I use some kind of numeric code as the principal name, generally (if the data is coming from an ERP) the surrogate key of the relevant field. Aliases are more descriptive. That being the case they should never collide. If there is a chance that they will (for example the employee ID dimension which has been populated over the years from various different payroll systems, some of which use the same ID codes) I append a character in front of the source system's ID code to show the source of the element. Again, no risk of a collision with pre-existing aliases. That being the case, for mine the DimIX is just a waste of processing cycles.

However I may feel differently were I to inherit a cube with a dimension which had that risk already built into it...