TM1 Forum

Admin Edit: Split from this thread since it's more in the nature of a general query than an enhancement request.

Hi Alan,

Your reply for CellsUpdateable is intersting. Now I met the same problem here:
ElseIf ( l_Writeable = 0);
# Bang user on head with frying pan and tell them to stop trying to write to consolidations or rules elements, or whatever

My l_Writeable is 0. But I really need to write the value to such "consolidations or rules elements". In my case, it might be "rules elements". How should I do? Is there a way to break the rules for these cells, after the write value to them, build the rules to them again?

Thanks.

LP_user

Alan Kirk wrote:

Steve Vincent wrote:This could have been made twice as useful as it is had someone thought about it more...

CellIsUpdateable checks if a cell can be written to, but it FAILS if one of the elements doesn't exist. Rather than failing (and dumping things in to the error log) it should also return zero if the element is missing,

I doez disagree on this one. My belief is that a function return value should always have a specific and unambiguous meaning. Consequently I'd rather that if the element doesn't exist, it returns -1 rather than 0. The test for whether the cell is writeable can still be expressed as

Code: Select all

if (CellIsUpdateable(Blah)=1); 

or alternatively

Code: Select all

if (CellIsUpdateable(Blah)>0) 

so no changes to exisitng code would be needed, but if it returned -1 for a missing element then you'd have the option of using an If/Elseif block and save a little code and a few processing cycles:

Code: Select all

l_Writeable = CellIsUpdateable(Blah);

If ( l_Writeable <0);
    #Insert the element, write a log file, throw a party, whatever
ElseIf ( l_Writeable = 0);
    # Bang user on head with frying pan and tell them to stop trying to write to consolidations or rules elements, or whatever
Else;
    #Write your value and may the gods have mercy on your soul, etc
EndIf;

If you don't care whether it's un-writeable or simply doesn't exist, you could still use "< 1" as the test criterion.

LP_user wrote:Hi Alan,

Your reply for CellsUpdateable is intersting. Now I met the same problem here:
ElseIf ( l_Writeable = 0);
# Bang user on head with frying pan and tell them to stop trying to write to consolidations or rules elements, or whatever

My l_Writeable is 0. But I really need to write the value to such "consolidations or rules elements". In my case, it might be "rules elements". How should I do? Is there a way to break the rules for these cells, after the write value to them, build the rules to them again?

You can't write to a rules element at all unless the rule evaluates as Stet. Turning the rule off then writing something to the cell then turning the rule back on will simply result in the reactivated rule replacing the value that was written.

The way to approach this is to decide in advance what area of the cube needs to be inputable and then either:
(a) Not write a rule for it; or
(b) Write a rule which Stets that particular area of the cube.

If you describe in more detail what you're trying to achieve and why, someone may have other suggestions.

I agree with Alan.
Also I must add that sometimes I use this function in TM1 models, and sometimes I deliberately do not use it:
for example when the user needs to be warned about the fact that loading to some cell is not possible.
CellIsUpdateable would mask that kind of errors, leading for example to a different total in TM1 and the data source without notifying the user howcome.

[Off-topic]
I find the CellIncrementN function in TM1 v10 quite handy!
It saves us a few lines of code, but also, there are less hardcoded elements compared to 'CellGetN()+CellPutN()'.
[/Off-topic]

Hi Alan,

Thanks for you reply.

The backgroud for my question is that we need to copy the subset of the cube to the other subset of the same cube. Say, cube O, dimension A, we want to copy A->elem1 to A->elem2.

But there are some figures in A->elem2 subset. These figures should be deleted before copy. So I tried to program in prolog:

if (ViewExists(Cube, View) = 1); ViewDestroy(Cube, View); endif;
ViewCreate(Cube, View);

ViewExtractSkipCalcsSet (Cube, View, 1);
ViewExtractSkipRuleValuesSet (Cube, View, 0);
ViewExtractSkipZeroesSet (Cube, View, 1);

Dim = 'A';
Element = 'elem2';
if(SubsetExists (Dim, Subset) = 0); SubsetCreate(Dim, Subset); endif;
SubsetDeleteAllElements(Dim, Subset);
SubsetElementInsert(Dim, Subset, Element, 1);
ViewSubsetAssign(Cube, View, Dim, Subset);

#clear the data in view
ViewZeroOut(Cube, View);

Dim = 'A';
Element = 'elem1';
if(SubsetExists (Dim, Subset) = 0); SubsetCreate(Dim, Subset); endif;
SubsetDeleteAllElements(Dim, Subset);
SubsetElementInsert(Dim, Subset, Element, 1);
ViewSubsetAssign(Cube, View, Dim, Subset);
-----------------------------------------------
and in Data part, program like:
-------------------------------
Element = 'elem2';

if (CellIsUpdateable (blah..'elem2'= 0);
itemskip;
endif;


#****Begin: Generated Statements***
#****End: Generated Statements****

if (VALUE_IS_STRING=1,
CellPutS(blah..),
CellPutN(blah..));

But it doesn't work. The reason might be the elem1 and elem2 are rules elements.
So I have to delete the old figure in elem2 MANUALLY in cube O. Then execute the TI process to copy elem1 to elem2.
I also checked the rules for Dimension A. I can't use Stets to avoid the applying rules on the area of the cube. We really need the rules on this area of the cube.

Is there better way to do this work? I am tired of clear the figures in cube manually.

With best regards,

LP_user

I am also facing the same problem.
Sometimes, the rule must be evaluated, but sometimes it should be STET.
But regardless of whether there is a rule applied, i still want to ViewZeroOut that particular area of data.
Since we cannot specify any options in the ViewZeroOut method, i am still wondering how i should do this..