Musings on CellGetN vs DB(...) performance in rules

[garry cook]

So I had a blonde moment and coded a rule file in 10.2.2 SP2 with a CellGetN rather than DB as follows -

['Orig Val',{'EUR input','GBP input'},'2015']=N:
IF(CellGetN('z Control by Version','Most Likely Outcome','Current Month','Numeric')<ATTRN('Months', !Months, 'IndexN'),
blah);

which compiles fine, works properly and goes through the rule tracer properly, etc. Syntax error showed up when copying back to a 10.2 server and I realised that I've TI syntax'd rather than rule syntax so had to change it to the compilable correct syntax -

['Orig Val',{'EUR input','GBP input'},'2015']=N:
IF(DB('z Control by Version','Most Likely Outcome','Current Month','Numeric')<ATTRN('Months', !Months, 'IndexN'),
blah);

Have to be honest, I wasn't aware that they'd standardised the functions so came as somewhat of a surprise although to be fair I got bored reading the patch notes. Just wondering if anyone has tested this to see if there is any appreciable performance difference between the two syntax or if they had seen issues using CellGetN in rules.

Would be useful to do training for developers to have one standard function between both Rules and TI so just musing on if this is stable. Couldn't find it on a forum search so apologies if I've missed a thread.

TIA

[David Usherwood]

I've seen nothing announced. Since the functions do the same job, and you have been able to do the opposite for a number of versions (ie use DB in TI), I think it's an unintended side effect etc.

[lotsaram]

I've seen nothing announced. Since the functions do the same job, and you have been able to do the opposite for a number of versions (ie use DB in TI), I think it's an unintended side effect etc.

Never knew that. Since DB() is ambidextrous when it comes to string vs. numeric data what does the TI editor do when you initialize a variable with DB() on the RHS?

[Wim Gielis]

I've seen nothing announced. Since the functions do the same job, and you have been able to do the opposite for a number of versions (ie use DB in TI), I think it's an unintended side effect etc.

Hello David,

I cannot make it working in a simple TI process without data source.

This works fine (obviously):

Code: Select all

Ascii0utput( 'test.txt', NumberToString(CellGetN('Posts', 'Year 2014', 'Excel related', 'Number of posts')));

while this throws an error at me when saving the TI process:

Code: Select all

Ascii0utput( 'test.txt', NumberToString(DB('Posts', 'Year 2014', 'Excel related', 'Number of posts')));

Error: variable "db" is undefined.

Can you please provide more details?

Tested with TM1 10.2.2, last but one FP.

Thanks !

[David Usherwood]

Seems like a senior moment....

DB
DB returns a value from a cube in a TM1® database. DB returns a numeric value if used in a numeric expression and a string value if used in a string expression.

This is a TM1 rules function, valid in TM1 rules only. Use of this function in a TurboIntegrator process will cause an error.

(From 10.2.2)
Possibly it was supported in earlier versions but I'm not planning to excavate until I find the right version.

[Wim Gielis]

Possibly it was supported in earlier versions but I'm not planning to excavate until I find the right version.

Me neither

[Alan Kirk]

This works fine (obviously):

Code: Select all

Ascii0utput( 'test.txt', NumberToString(CellGetN('Posts', 'Year 2014', 'Excel related', 'Number of posts')));

It does?? 'Cos when I copied that to paste it into my TI I found that the 0 in AsciiOutput was a zero instead of a letter O! (Yes, I know only too well the perils of air code myself, so I say this merely in jest, I assure you.)

Possibly it was supported in earlier versions but I'm not planning to excavate until I find the right version.

Me neither

I think you guys will be looking back a fair way. My operational version is 9.5.2, and it didn't work there. However I also still have a VM which was used as a testbed for our old production version of 9.0 SP3... and it threw the same error. So if it actually worked and Garry wasn't just having a bad dream, it sounds like it was a glitch that was specific to a particular service pack. Either that or it's something from way back in version 8-land, but Garry indicated that it was fresh code rather than something that was dug out of an ancient boneyard.

[Wim Gielis]

This works fine (obviously):

Code: Select all

Ascii0utput( 'test.txt', NumberToString(CellGetN('Posts', 'Year 2014', 'Excel related', 'Number of posts')));

It does?? 'Cos when I copied that to paste it into my TI I found that the 0 in AsciiOutput was a zero instead of a letter O! (Yes, I know only too well the perils of air code myself, so I say this merely in jest, I assure you.)

No, it doesn't work like that because of the 0
I was making sure I had CamelCase function names in my posted code, and I must have done a bad typ0

[garry cook]

So if it actually worked and Garry wasn't just having a bad dream, it sounds like it was a glitch that was specific to a particular service pack. Either that or it's something from way back in version 8-land, but Garry indicated that it was fresh code rather than something that was dug out of an ancient boneyard.

It's fresh code in 10.2.2 SP2 but it's the other way round I'd noticed - CellGetN working in Rules rather than DB working in TI which was news to me. Wouldn't compile in 10.2.0 which is when I realised I'd coded the wrong way round. Pretty sure it didn't allow DB in TI in version 8.1.8 (or indeed 7.1.4) as I remember being really annoyed that two different syntax was required for the same function but that was a loooong time ago so memory is fuzzy on that.

And the only bad dream I seem to be unable to wake from was the Scottish Independence vote