DimensionDeleteAllElements does not "delete" element

[shockwave]

Hi All,

How do i permently delete an element from a dimension? Is the only way by destroying the dimension and rebuilding the hierarchy??
I have an issue where I get an "element is ambiguous" error within my rule file. I have written a script to identify what dimensions element
"x" exists in but when I go into the dimension to do a manual search for it within that dimension it does not show.

I understand the per the documentation "DimensionDeleteAllElements" it says it only deletes the data:

"NOTE: Deleting an element deletes all cube data identified by that element. However, if you use DimensionDeleteAllElements to delete elements, then recreate those elements with the same names in the Metadata tab, any data points in a cube identified by the elements will be retained after rebuilding the dimension.
This function is useful for recreating dimension hierarchies."

Can someone confirm that this is the correct behaviour when using "DimensionDeleteAllElements" that old elements are never deleted unless the dimension is completely rebuilt.

Cheers

Shockwave

[tomok]

Can someone confirm that this is the correct behaviour when using "DimensionDeleteAllElements" that old elements are never deleted unless the dimension is completely rebuilt.

Actually DimensionDeleteAllElements does just exactly what the name implies, it deletes all elements from a dimension, leaving it empty. If you don't add the dimension elements back, inside the same TI process, then the data for those just deleted elements is going to disappear. You have just misinterpreted the instructions. If you use the DimensionDeleteAllElements function in your TI process just make sure you add back the elements you want to still be there somewhere in the same process or you will lose data. Deleting all the elements in one process and then adding them back in another is not going to cut it, you'll lose the data.

[Alan Kirk]

How do i permently delete an element from a dimension? Is the only way by destroying the dimension and rebuilding the hierarchy??
I have an issue where I get an "element is ambiguous" error within my rule file. I have written a script to identify what dimensions element
"x" exists in but when I go into the dimension to do a manual search for it within that dimension it does not show.

That suggests to me that there's something wrong with your script and it's misreporting. An element is either there or it's not; they don't "hide" and if you have security access, and it's really there, you'll see it.

I understand the per the documentation "DimensionDeleteAllElements" it says it only deletes the data:

No it doesn't; I agree with Tomok, you've misinterpreted what it's saying. However I don't see why you would be using that anyway; if you know the element name it would be better to use DimensionElementDelete. Using DimensionDeleteAllElements to get rid of a single element is like using a tactical nuclear weapon to swat a fly.

Just remember to use it (either one, actually) on the Metadata tab, NOT the data tab.

[shockwave]

Hi Allan,

Nothing wrong with the script. The script picks up the fact the element exists in 2 dimensions. Maybe if have missing something????

NumDimensions = DIMSIZ('}Dimensions');
NumDimInit = 1;
dimNameStr = ',';
element='actVBudget';

While(NumDimInit<=NumDimensions);
dimName = DIMNM('}Dimensions', NumDimInit);

if(DIMIX(dimName, element)>0);
eleFound='Yes';
endif;

asciiOutPut('E:\Tm1 Uploads\DATA\Current\dimensionString.txt',dimName,eleFound);
eleFound='';
NumDimInit = NumDimInit + 1;
End;


While performing a search within the dimensinon it returns nothing. I have admin rights and can see all elements within both dimensions... It just doesn't appear when searching for the element in question. I have exported the dimension and performed a search for the element in question and its not there. The "ambiguous" rule error tells me that it exists in more than 1 dimension. I do remember creating this element within this dimension and deleting a while back but suprised to see that it magically is still there...

Shock

[Alan Kirk]

Hi Allan,

Nothing wrong with the script. The script picks up the fact the element exists in 2 dimensions. Maybe if have missing something????

Aside from the spelling of my name there's nothing obviously wrong there.

(Also aside from the fact that for safety's sake eleFound should be initialised at the top of the loop, not the bottom so that there's no risk of a line of code encountering it in an uninitialised state.)

While performing a search within the dimensinon it returns nothing. I have admin rights and can see all elements within both dimensions... It just doesn't appear when searching for the element in question. I have exported the dimension and performed a search for the element in question and its not there.

And did you export and check all of the alises as well? DimIx won't only return a non-zero value on the element base name...

[shockwave]

Hi Allan,

Made the script change as suggested. Spelling is correct and it still picks it up even though I cannot visibly see it on screen when i search for it or when i export the dimensions


NumDimensions = DIMSIZ('}Dimensions');
NumDimInit = 1;
dimNameStr = ',';
element='actVBudget';
eleFound='';

While(NumDimInit<=NumDimensions);
dimName = DIMNM('}Dimensions', NumDimInit);

if(DIMIX(dimName, element)>0);
eleFound='Yes';
else;
eleFound='No';
endif;

asciiOutPut('E:\Tm1 Uploads\DATA\Current\dimensionString.txt',dimName,eleFound);

NumDimInit = NumDimInit + 1;
End;

Checked the aliases as well....
Is this some sort of bug?

Cheers

Shock

[shockwave]

just had a thought it.... it might be the blob file... hmm

[shockwave]

thinking our aloud, ignore last post.

[Martin Ryan]

You know which element is ambiguous? Try copying and pasting the name of that element into all the dimensions in that cube. If it's an alias then it will still paste, but show the original name. If it doesn't exist in the dimension as an element or an alias then it will tell you it can't paste it in. Hopefully you should find that it pastes into two or more of the dimensions.

If that doesn't yield anything then I'd try deleting the rule and recreating it.

Martin

[Alan Kirk]

Hi Allan,

Made the script change as suggested. Spelling is correct

I meant the spelling of my name, which is still incorrect. Not as incorrect as when Martin is referred to as "Ryan", but incorrect nonetheless.

and it still picks it up even though I cannot visibly see it on screen when i search for it or when i export the dimensions

NumDimensions = DIMSIZ('}Dimensions');
NumDimInit = 1;
dimNameStr = ',';
element='actVBudget';
eleFound='';

While(NumDimInit<=NumDimensions);
dimName = DIMNM('}Dimensions', NumDimInit);

if(DIMIX(dimName, element)>0);
eleFound='Yes';
else;
eleFound='No';
endif;

asciiOutPut('E:\Tm1 Uploads\DATA\Current\dimensionString.txt',dimName,eleFound);

NumDimInit = NumDimInit + 1;
End;

Checked the aliases as well....
Is this some sort of bug?

I'd be reluctant to jump to that conclusion on functionality which is as basic as this. If it doesn't breach confidentiality you could always load the dimensions in which the script finds the element as attachments to a post; it would be worthwhile seeing whether it can be replicated by anyone else.

[shockwave]

Sorry Alan, i believe this is not the first time i have mis-spelt your name. Thanks for your help.

Cheers

Shcok

[paulsimon]

Hi

I think that there are two possible things going on here.

1) You have a rule where you are using the [] notation on the right or left side. This works fine so long as elements are unique across all elements in ALL dimensions. However, if you have a Product Code of '10001' and a Nominal of '10001' then the rules will have a hard time knowing whether you mean that they should apply to a Product or a Nominal.

Whenever you modify a dimension with something like DimensionDeleteAllElements, TM1 has to re-check rules. I would guess that the error has been there all along and that the forced re-checking of the rules is throwing up the error.

One answer is to prefix all elements with a suitable prefix, eg P for Product. I tend to recommend this for this very reason.

The other is to prefix the element names in the rules so you have eg ['Nominal:10001'] so that TM1 knows whether you mean '10001' as a Nominal or a Product.

I suspect that the error in the rules is causing DimensionDeleteAllElements to fail and therefore it isn't deleting all elements. (By the way most people recommend a routine that just breaks consolidation links rather than Deleting all elements and rebuilding because of the risks involved if the re-build doesn't work).

2) While I think that (1) is more likely the other possibility is that, if you are using rules in an }ElementAttributes cube, then you can get a situation where the Alias of an Element is the same as the name of a different Element, or the Alias or another Element.

If you open this dimension up in the Element Attribute Editor, you will get a warning message saying that there are duplicate Aliases, and the offending items will be highlighted in Red, which makes them easier to spot.

Regards


Paul Simon

[shockwave]

Thanks Paul Simon,

Yep, to get around the rule error I just prefixed it with the dimension that i needed. Checked the all the alias's and there appears to be no double up with other elements within other dimensions.....
Going to let this lay to rest, at least i have a work around.

I did see you mention this:
"Alias of an Element is the same as the name of a different Element" and i think that this may be causing the issue. Within my version dimension there is an attribute value "act v budget", this looks like it might be causing the problem ( i think alan mentioned this b4 but i overlooked it - i was looking at the elements NOT the attribute value of the element). Strangly the name is the same but without the space's. TM1 must ignore the spaces???

Cheers

Shock

[Martin Ryan]

TM1 must ignore the spaces???

Yes TM1 is space and case insensitive (except for a few gotchas like the long function).

[shockwave]

Thanks Martin, after 4 yrs of using this product, it still amaze's me there are still things to be learnt.

Cheers

Shock

[lotsaram]

TM1 must ignore the spaces???

Yes TM1 is space and case insensitive (except for a few gotchas like the long function).

and SCAN

[jstrygner]

Did a quick search on forum, but did not find anything.
What about Long and Scan functions? Where does the case matter?
I used them in my projects, and never had problems (now I start thinking, maybe I had, just wasn't aware of them).

[Alan Kirk]

Did a quick search on forum, but did not find anything.
What about Long and Scan functions? Where does the case matter?
I used them in my projects, and never had problems (now I start thinking, maybe I had, just wasn't aware of them).

It's not case that matters in Long, it's spaces; they were discussing both above. Both matter in Scan:

Code: Select all

SC_OUTFILE = 'C:\Temp\CaseDemo.txt';

#Note the TWO spaces between the words.
s_ToSearch = 'The  STRING';

# Returns 0 because the search is case sensitive
# and the lower case word 'string' is not there.
l_ScanNoCase = Scan('string', s_ToSearch);

AsciiOutput ( SC_OUTFILE, 'No Case', Str ( l_ScanNoCase, 1, 0 ));

# Returns 6, because it finds the case sensitive match after
# the two spaces.
l_ScanCase = Scan('STRING', s_ToSearch);

AsciiOutput ( SC_OUTFILE, 'Case', Str ( l_ScanCase, 1, 0 ));

# Returns 11 because the double space is counted, meaning that it 
# is SPACE sensitive.
l_Long = Long ( s_ToSearch );

AsciiOutput ( SC_OUTFILE, 'Long', Str ( l_Long, 2, 0 ));

The way around the Scan issue is to convert both the string being searched and the substring into upper or lower case (depending on your coding standards) with the Upper() or Lower() functions. Multiple spaces can be dealt with with the Trim() function if they're on the end(s) of the string, otherwise it's necessary to use an alternative way to strip them out like a While loop.