Problem with IF...ENDIF and assigning a value to a variable

Post Reply
User avatar
PavoGa
MVP
Posts: 622
Joined: Thu Apr 18, 2013 6:59 pm
OLAP Product: TM1
Version: 10.2.2 FP7, PA2.0.9.1
Excel Version: 2013 PAW
Location: Charleston, Tennessee

Problem with IF...ENDIF and assigning a value to a variable

Post by PavoGa »

I want to assign either a string or numeric value to a variable depending on a conditional test. I am somewhat surprised TM1 complains about this code reporting that vS: invalid numeric expression when trying to save the TI.

Code: Select all


vParam = 'pnDebug';
vtest = IF(SUBST(vParam, 2, 1) @= 'S', 1, 0);
vN = CellGetN(cubProcessControl, sProcess, '0', 'ParamNValue');
vS = CellGetS(cubProcessControl, sProcess, '0', 'ParamSValue');

# v3 is not declared until here
IF(vTest = 0);
    v3 = vN;
ENDIF;
IF(vTest = 1);
    v3 = vS;
ENDIF;

# this complains as well:
IF(vTest = 0);
    v3 = vN;
ELSE;
    v3 = vS;
ENDIF;
I do not recall ever having seen this before and am somewhat surprised that TM1 is assigning a value type to V3 within the context of the first conditional statement. (It does. If I reverse the latter two vTest conditionals, then the complaint becomes vN: invalid string expression )

So no such thing, apparently, as conditional variable declarations in a TI. As you might surmise, I'm trying to pseudo dynamically pass parameters to a sub-process based on cube values for ExecuteProcess or RunProcess. This is not a problem with TM1RunTI as the execution string can be built as needed.

Guess I've just never run into this before. Any suggestions for accomplishing what I'm trying to do? I can work around it by modifying the sub-processes. May test reading a cubeview and using SValue/NValue.
Ty
Cleveland, TN
tomok
MVP
Posts: 2836
Joined: Tue Feb 16, 2010 2:39 pm
OLAP Product: TM1, Palo
Version: Beginning of time thru 10.2
Excel Version: 2003-2007-2010-2013
Location: Atlanta, GA
Contact:

Re: Problem with IF...ENDIF and assigning a value to a variable

Post by tomok »

I think the key is the syntax checker is not smart enough to follow conditional logic. It just looks at the code and barks if it thinks something is wrong. Since the first mention of V3 in your code is to set it to VN, which is a numerical, it thinks V3 is a numerical variable. Your next mention of V3 is to attempt to set it equal to a string variable. That is a syntax error. I don't know of any way around this except to have all your variables be strings and convert them to numeric via StringToNumber whenever you need to use them.
Tom O'Kelley - Manager Finance Systems
American Tower
http://www.onlinecourtreservations.com/
User avatar
PavoGa
MVP
Posts: 622
Joined: Thu Apr 18, 2013 6:59 pm
OLAP Product: TM1
Version: 10.2.2 FP7, PA2.0.9.1
Excel Version: 2013 PAW
Location: Charleston, Tennessee

Re: Problem with IF...ENDIF and assigning a value to a variable

Post by PavoGa »

Tom,

Agreed. Here is what I was really trying to do:

Code: Select all

IF (nNumberOfParams = 1);
    ExecuteProcess(sProcess,
        CellGetS(cubProcessControl, sProcess, '0', 'ParamName'), IF(SUBST(CellGetS(cubProcessControl, sProcess, '0', 'ParamName'), 2, 1) @= 'S', CellGetS(cubProcessControl, sProcess, '0', 'ParamSValue'), CellGetN(cubProcessControl, sProcess, '0', 'ParamNValue')));
ELSEIF( nNumberOfParams = 2);
    ExecuteProcess(sProcess,
        CellGetS(cubProcessControl, sProcess, '0', 'ParamName'), IF(SUBST(CellGetS(cubProcessControl, sProcess, '0', 'ParamName'), 2, 1) @= 'S', CellGetS(cubProcessControl, sProcess, '0', 'ParamSValue'), CellGetN(cubProcessControl, sProcess, '0', 'ParamNValue')),
        CellGetS(cubProcessControl, sProcess, '1', 'ParamName'), IF(SUBST(CellGetS(cubProcessControl, sProcess, '1', 'ParamName'), 2, 1) @= 'S', CellGetS(cubProcessControl, sProcess, '1', 'ParamSValue'), CellGetN(cubProcessControl, sProcess, '1', 'ParamNValue')));
...
ENDIF;
In short, using a master control process to run sub-processes through ExecuteProcess or RunProcess. But boils down to the same thing it seems, whatever is first in the IF() function, sets the tone.

This is frustrating. I want a nice clean way to structure subprocesses to run that can be configurable without having every single parameter in the master process (only need four out of 16 total in the subs) and manage them within a cube. Guess I can do this by setting and passing the parameter values as strings. Then do whatever conversion is needed inside the sub-processes. <groaning> This was easy with TM1RunTI, but we have moved away from coding for that and using RunProcess for multi-threaded processing, plus also wanting to choose ExecuteProcess if desired.
Ty
Cleveland, TN
User avatar
Steve Rowe
Site Admin
Posts: 2456
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: TM1 v6,v7,v8,v9,v10,v11+PAW
Excel Version: Nearly all of them

Re: Problem with IF...ENDIF and assigning a value to a variable

Post by Steve Rowe »

Or don't use parameters at all and read the values directly from the control cubes in the TI concerned....This problem would then disappear. IMO if you have the parameter for a TI in a control cube then parameterising the TI is redundant and adds complexity.

Alternatively treat all parameters as strings and do the conversion at runtime in the TI.
Technical Director
www.infocat.co.uk
User avatar
PavoGa
MVP
Posts: 622
Joined: Thu Apr 18, 2013 6:59 pm
OLAP Product: TM1
Version: 10.2.2 FP7, PA2.0.9.1
Excel Version: 2013 PAW
Location: Charleston, Tennessee

Re: Problem with IF...ENDIF and assigning a value to a variable

Post by PavoGa »

Steve Rowe wrote: Wed Nov 25, 2020 1:37 pm Or don't use parameters at all and read the values directly from the control cubes in the TI concerned....This problem would then disappear. IMO if you have the parameter for a TI in a control cube then parameterising the TI is redundant and adds complexity.

Alternatively treat all parameters as strings and do the conversion at runtime in the TI.
Adding string parameter versions of the numeric parameters is what I did. So:

Code: Select all

pnPeriodNumber = IF(LONG(psPeriodNumber) > 0, NUMBR(psPeriodNumber), pnPeriodNumber);

and that avoided having to change a bunch of code. Not pretty, but it is what it is.
Ty
Cleveland, TN
Post Reply