aliases "malfunction"

[Chengooi]

I have a very wierd experience yesterdaya nd like to share with the world and hopefully someone can share their professional view with me.

one of my dimension structure .xdi was set up as follow:

Index name
T10010 "TM1 descriptions" DBSA formula to send the name "TM1 descriptions" to .dim file
T10011 "TM2 descriptions" DBSA formula to send the name "TM1 descriptions" to .dim file
so on and so forth

The structure has been working throughout the day and years but just yesterday at xx time, a user told me T10011 's alias has become TMx something else but not in any order ( not tm2 to T10010 ) , I then check both front door - it was showing as per claim , but the xdi was perfectly in order. I then press F9 to reestablish the dim and saved to dim , it actually restore the aliases to normal! Has anyone had that experience before or can someone tell me what could have cause it? any

[Alan Kirk]

I have a very wierd experience yesterdaya nd like to share with the world and hopefully someone can share their professional view with me.

one of my dimension structure .xdi was set up as follow:

Index name
T10010 "TM1 descriptions" DBSA formula to send the name "TM1 descriptions" to .dim file
T10011 "TM2 descriptions" DBSA formula to send the name "TM1 descriptions" to .dim file
so on and so forth

The structure has been working throughout the day and years but just yesterday at xx time, a user told me T10011 's alias has become TMx something else but not in any order ( not tm2 to T10010 ) , I then check both front door - it was showing as per claim , but the xdi was perfectly in order. I then press F9 to reestablish the dim and saved to dim , it actually restore the aliases to normal! Has anyone had that experience before or can someone tell me what could have cause it? any

I suggest that you (a) check the log files to see whether any users have made nefarious entries to the attributes cube for the dimension and (b) check that end users don't have write access to the attributes cube unless absolutely necessary.

Last time something like this happened to me it turned out that users had write access and one of them had accidentally changed the aliases.

[Chengooi]

I did already, the log shows my ID !!
I was doing the formula DBRA to read the alias of the index and then concatenate the DBRA formula with Elpar to find out the parent , I was able to see results accordingly on worksheet without realising the aliases in .dim file has changed??
I have "play" with TM1 for 3.5 years and never had experience this bizarre one!!
Could the concatenation of Elpar and DBRA caused the aliases go havoc!!

[Michel Zijlema]

I have a very wierd experience yesterdaya nd like to share with the world and hopefully someone can share their professional view with me.

one of my dimension structure .xdi was set up as follow:

Index name
T10010 "TM1 descriptions" DBSA formula to send the name "TM1 descriptions" to .dim file
T10011 "TM2 descriptions" DBSA formula to send the name "TM1 descriptions" to .dim file
so on and so forth

Hi Chengooi,

From your post I read that you try to load the same alias name to various different elements in the dimension. This is not possible - the alias is an alternative element name and (just as an element name) has to be unique.

Michel

[Chengooi]

No no, let me explained again but thanks for your feedback Micheal.

in the xdi file,
we used DBSA to send the alias name (alternate name) to the element.

But on a workbook, I used DBRA to read an index to retrieve it's alias name. e.g. someone give me T10010, I use formula
DBRA("Tm1adminhost:dimensionname","T10010",name) where name is the alias name field for T10010, you can call it BOB or whatever on xdi file.
I did not change the alias, the formula DBRA was simply retrieving the alias. DBSA send /change the aliases.
I do know the differences.
BUt what I also do was I concatenanate the DBRA formula with Elpar so I can find the parent of T10010 as well so I get name as well as it's parent, cool eh! but I suspect something has activated DBSA of whatever retrieved from ELPar ??!! I am just so shocked about it, I am still wondering why it happened and what REALLY had caused the aliases changed?

[Steve Rowe]

Chengooi,

Sometimes you have to just shrug your shoulders and move on

TM1 does sometimes do things that are totally unexplainable, it's often down to user error but sometimes not...
It's all part of the challenge of working with TM1!
Cheers,

[Steve Vincent]

DBRA is dangerous if you don't have the security setup correctly. If you type over a DBRA formula, it will send the value you type back in to the attribute, same way as DBRW will. I've done it myself by accident, so maybe something like that happened?

[Chengooi]

Thanks for all the comfort offered, yes, I will let it go this time
here is the formula I have used :
=DBRA("tm1qa:NewAccounts",ELPAR("tm1qa:NewAccounts",B7,1),"name")

[Chengooi]

Hi Steven

We do not have element security set up for the affected dimension , was that dangerous? was that what you meant?

[Alan Kirk]

DBRA is dangerous if you don't have the security setup correctly. If you type over a DBRA formula, it will send the value you type back in to the attribute, same way as DBRW will. I've done it myself by accident, so maybe something like that happened?

I'd bet that it WAS something like that, given that his name appeared in the logs. It doesn't sound like a glitch so much as an unintentional write. I concur that it's strongly advisable to set up security on those cubes to prevent write access by mortal users... though alas that wouldn't stop we Admins from writing if we make a mistake!

[Alan Kirk]

Hi Steven

We do not have element security set up for the affected dimension , was that dangerous? was that what you meant?

You don't need element security; if end users aren't permitted to make changes to the aliases or other attributes, you can just assign cube security. Give the users Read only access to the cube, and it'll prevent them from writing to it.

[mattgoff]

DBRA is dangerous if you don't have the security setup correctly. If you type over a DBRA formula, it will send the value you type back in to the attribute, same way as DBRW will. I've done it myself by accident, so maybe something like that happened?

I'd bet that it WAS something like that, given that his name appeared in the logs. It doesn't sound like a glitch so much as an unintentional write. I concur that it's strongly advisable to set up security on those cubes to prevent write access by mortal users... though alas that wouldn't stop we Admins from writing if we make a mistake!

Just today I had to remind a coworker that he should only be logging in to his "admin" account when he needed to do "admin" things and stick to his regular account the rest of the time. A bunch of budget currency rates kept disappearing even though I had very carefully set the security to protect them.... transaction log nicked him.

Matt

[Steve Vincent]

Alan hit the nail on the head, thats exactly what i meant