How to find an Attribute Type in a TI Process

Ideas and tips for enhancing your TM1 application
Post Reply
Carl Peach
Posts: 5
Joined: Tue Oct 04, 2011 2:55 pm
OLAP Product: TM1
Version: 9.4
Excel Version: 2003 2007

How to find an Attribute Type in a TI Process

Post by Carl Peach » Wed Oct 12, 2011 8:37 am

I am trying to use a TI process to copy a dimension and all it's associated attributes.

I cannot find a TI function to return the attribute type (text, numeric or alias).

When I tried to use DTYPE ( DimName, ElName ) on the }Element_Attributes dimension, I noticed that all the elements (attributes) are shown as n (numeric), so cannot use this.

Can anyone help please?

Thanks!

Duncan P
MVP
Posts: 587
Joined: Wed Aug 17, 2011 1:19 pm
OLAP Product: TM1
Version: 9.5.2 10.1 10.2
Excel Version: 2003 2007
Location: York, UK

Re: How to find an Attribute Type in a TI Process

Post by Duncan P » Wed Oct 12, 2011 11:09 am

This code works for me in 9.5 and I am pretty sure it did in 9.4 as well.

# Type may be AS, AN or AA for string, numeric or alias
attribute_type = DTYPE('}ElementAttributes_' | dimension_name, attribute_name);

I notice that you talk of an }Element_Attributes with an underscore between Element and Attributes. If that is not just a typo in your post and that is the name of the dimension you are querying then you will get an empty string. Because it is a rule function DTYPE will fail silently if the dimension or element does not exist.

lotsaram
MVP
Posts: 3094
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TM1, CX
Version: TM1 10.2.2 PA 2.0x
Excel Version: 2010 2013 365
Location: Switzerland

Re: How to find an Attribute Type in a TI Process

Post by lotsaram » Wed Oct 12, 2011 11:24 am

In subset editor the elements may all display as "N". However as Duncan explained DTYPE on an element of an attribute dimension will actually return AA, AS or AN.

If you are new to TM1 I wouldn't recommend setting out to do this yourself (at least not when there is a off the shelf process available that does exactly this already). You should look at http://code.bedrocktm1.org there are many more processes available beyond the one attached.
Attachments
Bedrock.Dim.Clone.pro
(6.64 KiB) Downloaded 327 times

Duncan P
MVP
Posts: 587
Joined: Wed Aug 17, 2011 1:19 pm
OLAP Product: TM1
Version: 9.5.2 10.1 10.2
Excel Version: 2003 2007
Location: York, UK

Re: How to find an Attribute Type in a TI Process

Post by Duncan P » Wed Oct 12, 2011 11:43 am

Further to what lotsaram said about how they appear in the subset editor, they actually seem to be implemented as string type elements so that if you write a rule on an }ElementAttributes_* cube all the definitions need to be of the form S:. This also has the effect that there is no consolidation of numeric attributes and numeric attribute values can be entered for consolidated items.

Carl Peach
Posts: 5
Joined: Tue Oct 04, 2011 2:55 pm
OLAP Product: TM1
Version: 9.4
Excel Version: 2003 2007

Re: How to find an Attribute Type in a TI Process

Post by Carl Peach » Wed Oct 12, 2011 12:49 pm

Thanks guys for the info. The underscore was a mistype in the post.

I didn't know that the DTYPE would resolve correctly, so a huge thanks for pointing that out.

On another note - do you know who was the author of the TI provided? The code and style of writing looks very similar to a consultant I worked with in Australia a few years ago.

Thanks again!!!

lotsaram
MVP
Posts: 3094
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TM1, CX
Version: TM1 10.2.2 PA 2.0x
Excel Version: 2010 2013 365
Location: Switzerland

Re: How to find an Attribute Type in a TI Process

Post by lotsaram » Wed Oct 12, 2011 12:53 pm

Carl Peach wrote:Thanks guys for the info. The underscore was a mistype in the post.

I didn't know that the DTYPE would resolve correctly, so a huge thanks for pointing that out.

On another note - do you know who was the author of the TI provided? The code and style of writing looks very similar to a consultant I worked with in Australia a few years ago.

Thanks again!!!
That would probably not be a coincidence ...

Post Reply