Page 1 of 1
Cell type is real
Posted: Mon Jul 21, 2014 1:45 pm
by BariAbdul
I am trying to do some basic data load of CurrentVersion and PreviousVersion data. My source is cube view.My Code in Prolog is:
Code: Select all
vCube='CPractive';
Dim='AVersion';
LoadVersion='201302';
Data tab:
[code
#****Begin: Generated Statements***
#****End: Generated Statements****
pCurrentVersion = Numbr(subst(LoadVersion, 2, 3));
pPrevVersion = pCurrentVersion - 1;
IF (pPrevVersion < 12);
mPrevVersion = '_0'|str(pPrevVersion,3,0);
Else;
mPrevVersion = '_'|str(pPrevVersion,4,0);
EndIF;
IF
( CellIsUpdateable('CPractive','Cost Centre7','LoadVersion','value')=1);
CELLPUTN(pCurrentVersion,'CPractive','Cost Centre7','LoadVersion','value');
ENDIF;
CellPutS(mPrevVersion, 'CPractive', 'Cost Centre7', 'PreviousVersion', 'value');
][/code]
The Process is saving fine but it is giving me an error “Cell Type is Real”. I understand that the message (
http://www.tm1forum.com/viewtopic.php?f ... 9&start=60)and played around by changing the element type as string but keep getting the same error

, Could someone please tell me I could I resolve it.Thanks in advance.
Re: Cell type is real
Posted: Mon Jul 21, 2014 1:52 pm
by BariAbdul
The variable tab is:
Re: Cell type is real
Posted: Mon Jul 21, 2014 1:59 pm
by lotsaram
"Cell type is real" is just TM1 telling you that you cant write text data to a numeric leaf cell.
Look at your 2 cell put statements.
Code: Select all
IF( CellIsUpdateable('CPractive','Cost Centre7','LoadVersion','value')=1);
CELLPUTN(pCurrentVersion,'CPractive','Cost Centre7','LoadVersion','value');
ENDIF;
CellPutS(mPrevVersion, 'CPractive', 'Cost Centre7', 'PreviousVersion', 'value');
I would assume that 'LoadVersion' and 'PreviousVersion' would be of the same element type, no? In which case no surprise that there is an error.
Re: Cell type is real
Posted: Mon Jul 21, 2014 2:08 pm
by BariAbdul
Thanks a lot Lotsaram.The loadVersion is numeric data type where as PreviousVersion is of String data type.
Re: Cell type is real
Posted: Mon Jul 21, 2014 2:26 pm
by lotsaram
BariAbdul wrote:Thanks a lot Lotsaram.The loadVersion is numeric data type where as PreviousVersion is of String data type.
In which case your error is that variable pCurrentVersion is of type string but you are attempting to use it in a CellPutN to a numeric cell.
Re: Cell type is real
Posted: Mon Jul 21, 2014 3:28 pm
by BariAbdul
Thanks for your valuable time,Strangely when I changed the data type of CurrentVersion and PreviousVersion to string the process ran successfully But there are no values in the cube ,It just displaying zeros,Any clues ,Please.
Re: Cell type is real
Posted: Wed Jul 23, 2014 8:16 am
by Steve Rowe
It is possible this CellIsUpdateable('CPractive','Cost Centre7','LoadVersion','value')=1); test is causing your TI to fail silently, comment it out to see whats really happening.
Re: Cell type is real
Posted: Wed Jul 23, 2014 8:38 am
by rmackenzie
Steve Rowe wrote:It is possible this CellIsUpdateable('CPractive','Cost Centre7','LoadVersion','value')=1); test is causing your TI to fail silently, comment it out to see whats really happening.
It's a good option given that there's a known bug (various TM1 versions) such that if an IF statement contains a CellGetN or S, CellIsUpdateable or AttrS and the function errors then the error doesn't properly 'bubble up' into the IF statement and the execution isn't stopped. Search the forum for extra reports on this.
The way to code around this is to declare a variable with the result of the test prior to the IF statement, i.e.:
Code: Select all
# put the test in a separate statement in case of error in the function
nTest = CellIsUpdateable('CPractive','Cost Centre7','LoadVersion','value');
# IF statement is now simplified from debugging point of view
IF ( nTest = 1 );
CELLPUTN(pCurrentVersion,'CPractive','Cost Centre7','LoadVersion','value');
ENDIF;
CellPutS(mPrevVersion, 'CPractive', 'Cost Centre7', 'PreviousVersion', 'value');
Some people might regard this as 'tidier' coding, even though it adds extra statements.
Re: Cell type is real
Posted: Wed Jul 23, 2014 9:55 am
by Steve Rowe
I wasn't really referring to a bug in the CellIsUpdateable more that if there is a fundamental issue with what the OP is trying to do, i.e. variables the wrong way round or the cellput would in fact *KeyError then the CellIsUpdateable would be masking these issues.
Not really a fan of using this command as a matter of course as it hides errors that you probably need to know about...
Re: Cell type is real
Posted: Tue Jun 30, 2015 2:47 pm
by Tilo
I have checked the threads referring to the error "cell type is real".
My Problem is that I have a check for the cell type and still get the error.
I copy data within a cube - string and numeric values.
A cube view is used as source.
Consolidated, calculated and zero value cells are excluded.
The source variables are all defined as string in the variables tab.
So the variable "Value" is defined as string.
IF (DType('vDim_last_dim_in_Cube',vDim_last_dim_in_Cube) @= 'N');
CellPutN(StringToNumber(Value), vCube, vDim1, vDim2, vDim3, ..., vDim_last_dim_in_Cube);
ELSE;
CellPutS(Value, vCube, vDim1, vDim2, vDim3, ..., vDim_last_dim_in_Cube);
ENDIF;
The error is thrown for the data tab for the code line "CellPutS(Value, vCube, vDim1, vDim2, vDim3, ..., vDim_last_dim_in_Cube);"
What could be the cause for the error?
Thanks
Tilo
Re: Cell type is real
Posted: Tue Jun 30, 2015 3:02 pm
by BariAbdul
I copy data within a cube - string and numeric values.
If you copying mixed data,Please look at the below post:
http://www.tm1forum.com/viewtopic.php?f=3&t=1109&p=6155 Thanks
Re: Cell type is real
Posted: Tue Jun 30, 2015 3:51 pm
by lotsaram
Tilo wrote:
IF (DType('vDim_last_dim_in_Cube',vDim_last_dim_in_Cube) @= 'N');
CellPutN(StringToNumber(Value), vCube, vDim1, vDim2, vDim3, ..., vDim_last_dim_in_Cube);
ELSE;
CellPutS(Value, vCube, vDim1, vDim2, vDim3, ..., vDim_last_dim_in_Cube);
ENDIF;
The error is thrown for the data tab for the code line "CellPutS(Value, vCube, vDim1, vDim2, vDim3, ..., vDim_last_dim_in_Cube);"
What could be the cause for the error?
The cause of the error is that you are trying to do a CellPutS into a numeric leaf cell. That much seems obvious from the error message.
However seem as the code is attempting to deal with this and branch into CellPutN and CellPutS a better question is why this is happening. I suspect that what you think is the last dimension of the cube is not really the
effective last dimension due to the cube being reordered. To make the code more generic and "future proof" you could instead use the 3 implicit variables at your disposal when using a cube view as the data source; value_is_string, nValue & sValue
E.g.
Code: Select all
IF( value_is_string = 1 );
CellPutN( nValue, vCube, vDim1, vDim2, vDim3, ..., vDim_last_dim_in_Cube );
ELSE;
CellPutS( sValue, vCube, vDim1, vDim2, vDim3, ..., vDim_last_dim_in_Cube );
ENDIF;
Re: Cell type is real
Posted: Tue Jun 30, 2015 4:35 pm
by Tilo
I actually meant ""Why do I get THIS error, though I "made sure" that I cannot get it"".
If I do not trust why should I not also consider that an error message could be misleading.
I have seen this in my life.
I should have mentioned that I checked the Cube order before with "reorder dimensions" in the Server Explorer and that we use TM1 10.2.2 FP3.
Is that enough proof?
Would a Loop using TabDim make sure to get the correct order - I guess so.
Here in this case:
DTYPE seems to be a problem - but not every TI execution (while always using the same test data situation) failed.
Working with VALUE_IS_STRING, SVALUE and NVALUE worked so far.
If the error comes up again despite using the variables I will post it.
Thanks for the help.
Re: Cell type is real
Posted: Tue Jun 30, 2015 8:34 pm
by lotsaram
Agree with you that error messages can sometimes be funky but that one seems unambiguous. If value_is_string is working without error then it would indicate that strings aren't being passed anymore to CellPutN
Tilo wrote:Would a Loop using TabDim make sure to get the correct order - I guess so.
I don't think so, I'm pretty sure TabDim will return the dimension names per the original index order of the cube. Just like DBRW and CellPutN always take the original dimension order.
I had assumed that you provided pseudo code. But if your code is actually verbatim copy/paste then it could explain your error.
IF (DType(
'vDim_last_dim_in_Cube',vDim_last_dim_in_Cube) @= 'N');
I assume there isn't actually a dimension called vDim_last_dim_in_Cube? If DType is passed in a 1st argument that isn't an actual dimension name I'm not sure what it would return but definitely not N, S or C.
Re: Cell type is real
Posted: Wed Jul 01, 2015 1:39 pm
by Tilo
Yes, it was pseudo code - regarding the Dimension Names.
But the Dimension and the variable containing the dimension elements have the same name and that is what I wanted to be reflected.
Who knows if this could not have been a Problem, too...
I do TM1 Support for Consulting customers and inhouse for several years and have opened 60 tickets for TM1 during the last two years only and have seen weird behaviour so often...
(let us not talk about the support...)
a)
My first thought was, that maybe in TM1 10.2.2 FP3 there is a different behaviour when importing N-Element-data into a variable that is defined with the string datatype.
This guy here describes something that leads into this direction:
http://dw.developer-works.com/article/1 ... om+process
b)
Thanks for the explanantion of the referred Dimension order with TabDim/DBRW/CellPutN.
I thought about a possible reason for the behaviour related to a) and b) as all bedrock processes use TabDim to get the Dimension order.